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La evolucion en el mercado de los procesadores y de los sistemas 
de procesamiento en general gira en torno a la integracion de mas 
unidades fisicas de procesamiento que permitan ejecutar una mayor 
cantidad de tareas de manera simultanea. Una de las principales con- 
secuencias de este planteamiento, desde el punto de vista de la pro- 
gramacion, es la necesidad de utilizar herramientas que permitan ges- 
tionar adecuadamente el acceso concurrente a recursos y datos por 
parte de distintos procesos o hilos de ejecucion, entre otros aspectos. 

Este libro pretende ser una contribucion, desde una perspectiva 
principalmente practica, al disefio y desarrollo de sistemas concurren- 
tes, haciendo especial hincapie en las herramientas que un programa- 
dor puede utilizar para llevar a cabo dicha tarea. Asi mismo, en este 
libro se introduce la importancia de estos aspectos en el ambito de los 
sistemas de tiempo real. 



Sobre este libro 

Este libro discute los principales contenidos teoricos y practicos de 
la asignatura Programacidn Concurrente y Tiempo Real, impartida en 
el segundo curso del Grado en Ingenieria Informatica de la Escuela 
Superior de Informatica de Ciudad Real (Universidad de Castilla-La 
Mancha). Puede obtener mas informacion sobre la asignatura, codigo 
fuente de los ejemplos, practicas de laboratorio y examenes en la web 
de la misma: http://www.libropctr.com. 

La version electronica de este libro puede descargarse desde la web 
anterior. La segunda edicion, actualizada y revisada para corregir erra- 
tas, del libro «fisico» puede adquirirse desde la pagina web de la edito- 
rial online Edlibrix en http://www.edlibrix.es. 
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Este libro recoge los aspectos fundamentales, desde una perspec- 
tiva esencialmente practica y en el ambito de los sistemas operatlvos, 
de Programacion Concurrente y de Tiempo Real, asignatura obligato- 
ria en el segundo curso del Grado en Ingenieria en Informatica en la 
Escuela Superior de Informatica (Universidad de Castilla-La Mancha). 
El principal objetivo que se pretende alcanzar es ofrecer al lector una 
vision general de las herramientas existentes para una adecuada pro- 
gramacion de sistemas concurrentes y de los principales aspectos de 
la planificacion de sistemas en tiempo real. 

La evolucion de los sistemas operativos modernos y el hardware de 
procesamiento, esencialmente multi-nucleo, hace especialmente rele- 
vante la adquisicion de competencias relativas a la programacion con- 
currente y a la sincronizacion y comunicacion entre procesos, para 
incrementar la productividad de las aplicaciones desarrolladas. En es- 
te contexto, el presente libro discute herramientas clasicas, como los 
semaforos y las colas de mensajes, y alternativas mas flexibles, como 
los monitores o los objetos protegidos. Desde el punto de vista de la 
implementacion se hace uso de la familia de estandares POSIX y de 
los lenguajes de programacion C, C++ y Ada. 

Por otra parte, en este libro tambien se discuten los fundamentos 
de la planificacion de sistemas en tiempo real con el objetivo de poner 
de manifiesto su importancia en el ambito de los sistemas criticos. 
Conceptos como el tiempo de respuesta o el deadline de una tarea son 
esenciales para la programacion de sistemas en tiempo real. 
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This book addresses, from a practical point of view and within the 
context of Operating Systems, the basics of Concurrent and Real-Time 
Programming, a mandatory course taught in the second course of the 
studies in Computer Science at the Faculty of Computing (University of 
Castilla-La Mancha) . The main goal of this book is to provide a general 
overview of the existing tools that can be used to tackle concurrent 
programming and to deal with real-time systems scheduling. 

Both the evolution of operating systems and processing hardware, 
especially multi-core processors, make the acquisition of concurrent 
programming-related competences essential in order to increase the 
performance of the developed applications. Within this context, this 
book describes in detail traditional tools, such as semaphores or mes- 
sage queues, and more flexible solutions, such as monitors or protec- 
ted objects. From the implementation point of view, the POSIX family 
of standards and the programming languages C, C++ and Ada are em- 
ployed. 

On the other hand, this book also discusses the basics of real-time 
systems scheduling so that the reader can appreciate the importance 
of this topic and how it affects to the design of critical systems. Con- 
cepts such as response time and deadline are essential to understand 
real-time systems programming. 
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Comunicando procesos 



Los procesos necesitan algun 
tipo de mecanismo explicito 
tanto para compartir infor- 
mation como para sincroni- 
zarse. El hecho de que se 
ejecuten en una misma ma- 
quina fisica no implica que 
los recursos se compartan de 
manera implicita sin proble- 
mas. 



En este capitulo se plantean los aspectos basicos relativos al 
concepto de proceso, estableciendo las principales diferen- 
cias con respecto a una hebra o hilo y haciendo especial hin- 
capie en su creacion y gestion mediante primitivas POSIX. Asi mismo, 
tambien se establece un marco general para el estudio de los fun- 
damentos de programacion concurrente. Estos aspectos se discutiran 
con mas detalle en sucesivos temas. 

La problematica que se pretende abordar mediante el estudio de 
la programacion concurrente esta vinculada al concepto de sistema 
operativo multiproceso, donde los procesos comparten todo tipo de 
recursos, desde la CPU hasta una impresora. Este planteamiento me- 
jora la eficiencia del sistema, pero plantea la cuestion de la sincro- 
nizacion en el acceso a los recursos. Tipicamente, esta problematica 
no se resuelve a nivel de sistema operativo, siendo responsabilidad del 
programador el garantizar un acceso consistente a los recursos. 

Este planteamiento general se introduce mediante el problema cla- 
sico del productor/consumidor, haciendo hincapie en la necesidad de 
compartir un buffer, y da lugar al concepto de seccion critica. Entre 
las soluciones planteadas, destaca el uso de los semaforos y el paso 
de mensajes como mecanismos clasicos de sincronizacion. 
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Figura 1.1: Esquema grafico de un programa y un proceso. 



1.1. El concepto de proceso 



Informalmente, un proceso se puede definir como un programa en 
ejecucion. Ademas del propio codigo al que esta vinculado, un proceso 
incluye el valor de un contador de programa y el contenido de ciertos 
registros del procesador. Generalmente, un proceso tambien incluye 
la pila del proceso, utilizada para almacenar datos temporales, como 
variables locales, direcciones de retorno y parametros de funciones, y 
una seccion de datos con variables globales. Finalmente, un proceso 
tambien puede tener una seccion de memoria reservada de manera 
dinamica. La figura 1.1 muestra la estructura general de un proceso. 



1.1.1. Gestion basica de procesos 

A medida que un proceso se ejecuta, este va cambiando de un es- 
tado a otro. Cada estado se define en base a la actividad desarrollada 
por un proceso en un instante de tiempo determinado. Un proceso 
puede estar en uno de los siguientes estados (ver figura 1.2): 



■ Nuevo, donde el proceso esta siendo creado. 

■ En ejecucion, donde el proceso esta ejecutando operaciones o 
instrucciones. 

■ En espera, donde el proceso esta a la espera de que se produzca 
un determinado evento, tipicamente la finalizacion de una opera- 
cion de E/S. 

■ Preparado, donde el proceso esta a la espera de que le asignen 
alguna unidad de procesamiento. 



1.1. El concepto de proceso 
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esperaE/S 



termination E/S 



Proceso init 



En sistemas UNIX y tipo 
UNIX, init (initialization) es el 
primer proceso en ejecucion, 
con PID 1, y es el responsa- 
ble de la creacion del resto de 
procesos. 



Figura 1.2: Diagrama general de los estados de un proceso. 

■ Terminado, donde el proceso ya ha finalizado su ejecucion. 

En UNIX, los procesos se identifican mediante un entero unico de- 
nominado ID del proceso. El proceso encargado de ejecutar la solici- 
tud para crear un proceso se denomina proceso padre, mientras que 
el nuevo proceso se denomina proceso hijo. Las primitivas POSIX uti- 
lizadas para obtener dichos identificadores son las siguientes: 



Listado 1.1: Primitivas POSIX ID Proceso 



#include <sys/types . h> 
finclude <unistd.h> 



pid_t getpid 
pid_t getppid 

uid_t getuid 
uid_t geteuid 



(void); // ID proceso. 

(void); // ID proceso padre. 

(void); // ID usuario. 

(void); // ID usuario efectivo. 



Las primitivas getpidQ y getppidQ se utilizan para obtener los iden- 
tificadores de un proceso, ya sea el suyo propio o el de su padre. 

Recuerde que UNIX asocia cada proceso con un usuario en parti- 
cular, comunmente denominado propietario del proceso. Al igual que 
ocurre con los procesos, cada usuario tiene asociado un ID unico den- 
tro del sistema, conocido como ID del usuario. Para obtener este ID 
se hace uso de la primitiva getuidQ. Debido a que el ID de un usuario 
puede cambiar con la ejecucion de un proceso, es posible utilizar la 
primitiva geteuidQ para obtener el ID del usuario efectivo. 



1.1.2. Primitivas basic as en POSIX 



La creacion de procesos en UNIX se realiza mediante la llamada al 
sistema forkQ. Basicamente, cuando un proceso realiza una llamada 
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a. forkQ se genera una copia exacta que deriva en un nuevo proceso, 
el proceso hijo, que recibe una copia del espacio de direcciones del 
proceso padre. A partir de ese momento, ambos procesos continuan 
su ejecucion en la instruccion que esta justo despues de forkQ. La 
figura 1.3 muestra de manera grafica las implicaciones derivadas de 
la ejecucion de forkQ para la creacion de un nuevo proceso. 



I^y^ /orfcfj devuelve 0 al proceso hijo y el PID del hijo al padre. 



Listado 1.2: La llamada fork() al sistema 



#include <sys /types . h> 
#include <unistd.h> 

3 

pid_t fork (void) ; 



Recuerde que forkQ devuelve el valor 0 al hijo y el PID del hijo al 
padre. Dicho valor permite distinguir entre el codigo del proceso pa- 
dre y del hijo, con el objetivo de tener la posibilidad de asignar un 
nuevo fragmento de codigo. En otro caso, la creacion de dos procesos 
totalmente identicos no seria muy util. 

proceso_A 



Independencia 



Los procesos son indepen- 
dientes entre si, por lo que no 
tienen mecanlsmos Implici- 
tos para compartir Informa- 
cion y sincronizarse. Incluso 
con la llamada forkQ, los pro- 
cesos padre e hijo son total- 
mente independientes. 



fork() 





hereda de 




Figura 1.3: Creacion de un proceso mediante forkQ. 
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El siguiente listado de codigo muestra un ejemplo muy basico de 
utilizacion de forkQ para la creacion de un nuevo proceso. No olvide 
que el proceso hijo recibe una copia exacta del espacio de direcciones 
del proceso padre. 



Listado 1.3: Uso basico de forkQ 



finclude <sys/types . h> 
finclude <unistd.h> 
finclude <stdlib.h> 
4 (finclude <stdio.h> 

5 

6 int main (void) { 

7 int *valor = malloc (sizeof (int) ) ; 

* valor = 0; 
9 fork(); 

10 tvalor = 13; 

11 printf("%ld: %d\n", (long) getpid ( ) , *valor) ; 

12 

13 free (valor) ; 

14 return 0; 

15 } 



La salida de este programa seria la siguiente 1 : 

13243: 13 
13244: 13 




^Como distinguiria el codigo del proceso hijo y el del padre? 



Despues de la ejecucion de forkQ, existen dos procesos y cada uno 
de ellos mantiene una copia de la variable valor. Antes de su ejecucion, 
solamente existia un proceso y una unica copia de dicha variable. Note 
que no es posible distinguir entre el proceso padre y el hijo, ya que no 
se controlo el valor devuelto por forkQ. 

Tipicamente sera necesario crear un numero arbitrario de procesos, 
por lo que el uso de forkQ estara ligado al de algun tipo de estructura 
de control, como por ejemplo un bucle for. Por ejemplo, el siguiente lis- 
tado de codigo genera una cadena de procesos, tal y como se refleja de 
manera grafica en la figura 1.4. Para ello, es necesario asegurarse de 
que el proceso generado por una llamada a forkQ, es decir, el proceso 
hijo, sea el responsable de crear un nuevo proceso. 



El valor de los ID de los procesos puede variar de una ejecucion a otra. 
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Figura 1.4: Cadena de procesos generada por el listado de codigo 
anexo. 



Anteriormente se comento que era necesario utilizar el valor devuel- 
to por fork() para poder asignar un codigo distinto al proceso padre y 
al hijo, respectivamente, despues de realizar dicha llamada. El uso de 
fork() por si solo es muy poco flexible y generaria una gran cantidad de 
codigo duplicado y de estructuras if-then-else para distinguir entre el 
proceso padre y el hijo. 

Idealmente, seria necesario algun tipo de mecanismo que posibi- 
litara asignar un nuevo modulo ejecutable a un proceso despues de 
su creacion. Este mecanismo es precisamente el esquema en el que 
se basa la familia exec de llamadas al sistema. Para ello, la forma de 
combinar forkf) y alguna primitiva de la familia exec se basa en per- 
mitir que el proceso hijo ejecute exec para el nuevo codigo, mientras 
que el padre continua con su flujo de ejecucion normal. La figura 1.5 
muestra de manera grafica dicho esquema. 



Listado 1.4: Creacion de una cadena de procesos 



#include <sys/types . h> 
5 include; <unistd.h> 
#include <stdio.h> 

4 

int main (void) { 

6 int i = 1 , n = 4 ; 

pid_t childpid; 

8 

9 for (i = 1; i < n; i++) { 
10 childpid = fork(); 

if (childpid > 0) // Codigo del padre, 
break; 

14 

15 printf ( "Proceso %ld con padre %ld\n", (long) getpid ( ) , 
(long) getppidO ) ; // £PID == 1? 

17 

18 pause ( ) ; 
19 

20 return 0; 



1.1. El concepto de proceso 
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Figura 1.5: Esquema grafico de la combinacion JorkQ+execQ. 



El uso de operaciones del tipo exec implica que el proceso padre 
tenga que integrar algun tipo de mecanismo de espera para la correcta 
finalizacion de los procesos que creo con anterioridad, ademas de lle- 
var a cabo algun tipo de liberacion de recursos. Esta problematica se 
discutira mas adelante. Antes, se estudiara un ejemplo concreto y se 
comentaran las principales diferencias existentes entre las operacio- 
nes de la familia exec, las cuales se muestran en el siguiente listado 
de codigo. 



Listado 1.5: Familia de Uamadas exec 



# include <unistd.h> 

2 

int execl (const char *path, const char *arg, . . . ) ; 
int execlp (const char *file, const char *arg, ...); 
5 int execle (const char *path, const char *arg, 
char *const envp [ ] ) ; 

7 

int execv (const char *path, char *const arqv [ ] ) ; 
int execvp (const char *file, char *const arqv [ ] ) ; 
int execve (const char *path, char *const argv[], 
11 char *const envp ( ] ) ; 



La llamada al sistema execty tiene los siguientes parametros: 

1. La ruta al archivo que contiene el codigo binario a ejecutar por 
el proceso, es decir, el ejecutable asociado al nuevo segmento de 
codigo. 
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2. Una serie de argumentos de linea de comandos, terminado por 
un apuntador a NULL. El nombre del programa asociado al proce- 
so que ejecuta execl suele ser el primer argumento de esta serie. 



La llamada execlp tiene los mismos parametros que execl, pero 
hace uso de la variable de entorno PATH para buscar el ejecutable 
del proceso. Por otra parte, execle es tambien similar a execl, pero 
afiade un parametro adicional que representa el nuevo ambiente del 
programa a ejecutar. Finalmente, las llamadas execv difieren en la 
forma de pasar los argumentos de linea de comandos, ya que hacen 
uso de una sintaxis basada en arrays. 

El siguiente listado de codigo muestra la estructura de un progra- 
ma encargado de la creacion de una serie de procesos mediante la 
combinacion deforkQ y execlf) dentro de una estructura de bucle. 

Como se puede apreciar, el programa recoge por linea de ordenes el 
mimero de procesos que se crearan posteriormente 2 . Note como se ha- 
ce uso de una estructura condicional para diferenciar entre el codigo 
asociado al proceso padre y al proceso hijo. Para ello, el valor devuelto 
por fork(j, almacenado en la variable childpid, actua de discriminante. 

En el case 0 de la sentencia switch (linea fU]) se ejecuta el codigo 
del hijo. Recuerde que forkf) devuelve 0 al proceso hijo, por lo que en 
ese caso habra que asociar el codigo del proceso hijo. En este ejemplo, 
dicho codigo reside en una nueva unidad ejecutable, la cual se en- 
cuentra en el directorio exec y se denomina hijo. Esta informacion es 
la que se usa cuando se llama a execlQ. Note como este nuevo proceso 
acepta por linea de ordenes el numero de procesos creados [argv[l]), 
recogido previamente por el proceso padre (linea (~TT)). 



Listado 1.6: Uso de fork+exec 



i 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 



#include <sys /types . h> 
#include <unistd.h> 
#include <stdlib.h> 
#include <stdio.h> 

int main (int argc, char *argv[]) { 
pid_t childpid; 
int n = atoi (argv [ 1 ] ) , i; 

for (i = 1; i <= n; i++) 

switch (childpid = fork()) { 
case 0: // Codigo del hijo. 

execl (". /exec/hi jo" , "hijo", argv[l], NULL), 
break; // Para evitar entrar en el for. 



// Se obvia la espera a los procesos 
// y la captura de eventos de teclado. 

return 0 ; 



padre 




Figura 1.6: Representacion 
grafica de la creacion de va- 
rios procesos hijo a partir de 
uno padre. 



Compilacion 



La compilacion de los pro- 
gramas asociados al proceso 
padre y al hijo, respectiva- 
mente, es independiente. En 
otras palabras, seran objeti- 
vos distintos que generaran 
ejecutables distintos. 



2 Por simplificacion no se lleva a cabo un control de errores 
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El nuevo codigo del proceso hijo es trivial y simplemente imprime 
el ID del proceso y el numero de hermanos que tiene. Este tipo de 
esquemas, en los que se estructura el codigo del proceso padre y de 
los hijos en ficheros fuente independientes, sera el que se utilice en 
los temas sucesivos. 

En este punto, resulta interesante preguntarse sobre lo que suce- 
de con el proceso padre despues de la creacion de los procesos hijo. 
Hasta ahora se ha planteado que ambos siguen su ejecucion desde la 
instruccion siguiente aforkQ. Sin embargo, si un padre desea esperar 
a que su hijo termine, entonces ha de ejecutar una llamada explicita 
a waitQ o alguna funcion similar. 



Listado 1.7: Codigo del proceso hijo 



1 #include <sys/types . h> 
finclude <unistd.h> 
finclude <stdlib.h> 

4 (finclude <stdio.h> 

5 

5 void hijo (const char *num_hermanos ) ; 

7 

8 int main (int argc, char *argv[]) { 
hijo (argv [ 1 ] ) ; 
return 0 ; 

11 } 
12 

13 void hijo (const char *num_hermanos ) { 

14 printf ("Soy %ld y tengo %d hermanos ! \n" , 

(long) getpid ( ) , atoi (num_hermanos ) - 1); 

16 } 



La llamada waitQ detiene el proceso que llama hasta que un hijo de 
dicho proceso finance o se detenga, o hasta que el proceso que realizo 
dicha llamada reciba otra serial (como la de terminacion). Por ejemplo, 
el estandar POSIX define SIGCHLD como la serial enviada a un pro- 
ceso cuando su proceso hijo finaliza su ejecucion. Otra serial esencial 
esta representada por SIGINT, enviada a un proceso cuando el usuario 
desea interrumpirlo. Esta serial se representa tipicamente mediante la 
combinacion Ctrl+C desde el terminal que controla el proceso. 



Listado 1.8: Primitivas POSIX wait 



#include <sys/types . h> 
(finclude <sys/wait.h> 

3 

i pid_t wait (int *status); 

5 pid_t waitpid (pid_t pid, int *status, int options); 

6 

7 // BSD style 

8 pid_t wait3 (int *status, int options, 

struct rusage *rusage) ; 

10 pid_t wait4 (pid_t pid, int *status, int options, 

11 struct rusage *rusage) ; 
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Listado 1.9: Uso de fork+exec+wait 



#include <sys/types . h> 
#include <unistd.h> 
#include <stdlib.h> 
4 #include <stdio.h> 
5 include <signal.h> 
5 include <wait.h> 

7 

#define NUM_HIJ0S 5 

9 

10 void f inalizarprocesos (); 

11 void controlador (int senhal); 
12 

13 pid_t pids [NUM_HIJ0S] ; 

14 

15 int main (int argc, char *argv[]) { 

16 int i; 

17 char *num_hi jos_str; 

num_hi jos_str = (char* ) malloc (sizeof (int )) ; 

19 sprintf (num_hi jos_str, "%d", NUM_HIJ0S); 

20 

21 // Manejo de Ctrol+C. 

22 if (signal (SIGINT, controlador) == SIG_ERR) { 

fprintf (stderr, "Abrupt termination . \n" ) ; 
24 exit (EXIT_FAILURE) ; 

} 

26 

for (i = 0; i < NUM_HIJ0S; i++) 

28 switch (pids [i] = fork()) { 

29 case 0: // Codigo del hijo. 

execl (". /exec/hi jo" , "hijo", num_hi jos_str , NULL); 
break; // Para evitar entrar en el for. 

32 } 
33 

34 f ree (num_hi jos_str) ; 

35 

36 // Espera terminacion de hijos. . . 

37 for (i = 0; i < NUM_HIJ0S; i++) 

38 waitpid (pids [i] , 0, 0); 
39 

40 return EXIT_SUCCESS ; 

41 } 
42 

43 void f inalizarprocesos () { 

44 int i; 

45 printf ("\n Finalizacion de procesos 

\n"); 

for (i = 0; i < NUM_HIJ0S; i++) 
47 if (pids [i] ) { 

printf ( "Finalizando proceso [ %d] . . . ", pids[i]); 

49 kill (pids [i] , SIGINT) ; pr int f ( " <0k>\n" ) ; 

50 } 

51 } 
52 

53 void controlador (int senhal) { 

54 printf (" \nCtrl + c captured . \n" ) ; printf ( "Terminating ... \n\n" ) ; 

55 // Liberar recursos. . . 

56 f inalizarprocesos () ; 

57 exit (EXIT_SUCCESS) ; 

58 } 
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El anterior listado muestra la inclusion del codigo necesario pa- 
ra esperar de manera adecuada la fmalizacion de los procesos hijo y 
gestionar la terminacion abrupta del proceso padre mediante la com- 
binacion de teclas Ctrl+C. 

En primer lugar, la espera a la terminacion de los hijos se con- 
trola mediante las lineas [ 37-38) utilizando la primitiva waitpid. Esta 
primitiva se comporta de manera analoga a wait, aunque bloquean- 
do al proceso que la ejecuta para esperar a otro proceso con un pid 
concrete Note como previamente se ha utilizado un array auxiliar de- 
nominado pids (linea ( TT )) para almacenar el pid de todos y cada uno 
de los procesos hijos creados mediante _/brk (linea fiF]). Asi, solo habra 
que esperarlos despues de haberlos lanzado. 

Por otra parte, note como se captura la serial SIGINT, es decir, la 
terminacion mediante Ctrl+C, mediante la funcion signal (linea (22J), la 
cual permite asociar la captura de una senal con una funcion de re- 
trollamada. Esta funcion definira el codigo que se tendra que ejecutar 
cuando se capture dicha senal. Basicamente, en esta ultima funcion, 
denominada controlador, se incluira el codigo necesario para liberar 
los recursos previamente reservados, como por ejemplo la memoria 
dinamica, y para destruir los procesos hijo que no hayan finalizado. 

Si signalQ devuelve un codigo de error SIG_ERR, el programador es 
responsable de controlar dicha situacion excepcional. 



Listado 1.10: Primitiva POSIX signal 



# include <signal.h> 

2 

typedef void (*sighandler_t) (int) ; 

4 

5 sighandler_t signal {int signum, sighandler_t handler) ; 



1.1.3. Procesos e hilos 



Sincronizacion 



Conseguir que dos cosas 
ocurran al mismo tiempo se 
denomlna comunmente sin- 
cronizacion. En Informatica, 
este concepto se asocia a 
las relaciones existentes en- 
tre eventos, como la seriali- 
zacion (A debe ocurrir antes 
que B) o la exclusion mutua 
(A y B no pueden ocurrir al 
mismo tiempo). 



El modelo de proceso presentado hasta ahora se basa en un unico 
flujo o hebra de ejecucion. Sin embargo, los sistemas operativos mo- 
dernos se basan en el principio de la multiprogramacion. es decir, en 
la posibilidad de manejar distintas hebras o hilos de ejecucion de ma- 
nera simultanea con el objetivo de paralelizar el codigo e incrementar 
el rendimiento de la aplicacion. 

Esta idea tambien se plasma a nivel de lenguaje de programacion. 
Algunos ejemplos representativos son los APIs de las bibliotecas de 
hilos Pthread, Win32 o Java. Incluso existen bibliotecas de gestion 
de hilos que se enmarcan en capas software situadas sobre la capa 
del sistema operativo, con el objetivo de independizar el modelo de 
programacion del propio sistema operativo subyacente. 

En este contexto, una hebra o hilo se define como la unidad basica 
de utilizacion del procesador y esta compuesto por los elementos: 



Un ID de hebra, similar al ID de proceso. 
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codigo 


datos 


archivos 


registros 




pila 



codigo 


datos 


archivos 


registros 


registros 


registros 




Figura 1.7: Esquema grafico de los modelos monohilo y multihilo. 

■ Un contador de programa. 

■ Un conjunto de registros. 

■ Una pila. 



Sin embargo, y a diferencia de un proceso, las hebras que perte- 
necen a un mismo proceso comparten la seccion de codigo, la seccion 
de datos y otros recursos proporcionados por el sistema operativo, 
como los manejadores de los archivos abiertos o las sefiales. Precisa- 
mente, esta diferencia con respecto a un proceso es lo que supone su 
principal ventaja. 

Desde otro punto de vista, la idea de hilo surge de la posibilidad de 
compartir recursos y permitir el acceso concurrente a esos recursos. 
La unidad minima de ejecucion pasa a ser el hilo, asignable a un pro- 
cesador. Los hilos tienen el mismo codigo de programa, pero cada uno 
recorre su propio camino con su PC, es decir, tiene su propia situacion 
aunque dentro de un contexto de comparticion de recursos. 

Informalmente, un hilo se puede definir como un proceso ligero 

que tiene la misma funcionalidad que un proceso pesado, es decir, los 
mismos estados. Por ejemplo, si un hilo abre un fichero, este estara 
disponible para el resto de hilos de una tarea. 

En un procesador de textos, por ejemplo, es bastante comun en- 
contrar hilos para la gestion del teclado o la ejecucion del corrector 
ortograficos, respetivamente. Otro ejemplo podria ser un servidor web 
que manejara hilos independientes para atender las distintas peticio- 
nes entrantes. 

Las ventajas de la programacion multihilo se pueden resumir en 
las tres siguientes: 
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■ Capacidad de respuesta, ya que el uso de multiples hilos pro- 
porciona un enfoque muy flexible. Asi, es posible que un hilo se 
encuentra atendiendo una peticion de E/S mientras otro conti- 
nua con la ejecucion de otra funcionalidad distinta. Ademas, es 
posible plantear un esquema basado en el paralelismo no blo- 
queante en llamadas al sistema, es decir, un esquema basado en 
el bloqueo de un hilo a nivel individual. 

■ Comparticion de recursos, posibilitando que varios hilos mane- 
jen el mismo espacio de direcciones. 

■ Eficacia. ya que tanto la creacion, el cambio de contexto, la des- 
truccion y la liberacion de hilos es un orden de magnitud mas 
rapida que en el caso de los procesos pesados. Recuerde que las 
operaciones mas costosas implican el manejo de operaciones de 
E/S. Por otra parte, el uso de este tipo de programacion en ar- 
quitecturas de varios procesadores (o nucleos) incrementa enor- 
memente el rendimiento de la aplicacion. 



Caso de estudio. POSIX Pthreads 



POSIX 



Portable Operating System In- 
terface es una familia de es- 
tandares definidos por el co- 
mite IEEE con el objetivo de 
mantener la portabllldad en- 
tre dlstintos slstemas opera- 
tives. La X de POSIX es una 
referenda a slstemas Unix. 



Pthreads es un estandar POSIX que define un interfaz para la crea- 
cion y sincronizacion de hilos. Recuerde que se trata de una especifica- 
cion y no de una implementacion, siendo esta ultima responsabilidad 
del sistema operativo. 

El manejo basico de hilos mediante Pthreads implica el uso de las 
primitivas de creacion y de espera que se muestran a continuacion. 
Como se puede apreciar, la Uamada pthread_create() necesita una fun- 
cion que defina el codigo de ejecucion asociado al propio hilo (definido 
en el tercer parametro). Por otra parte, pthreadjoinO tiene un propo- 
sito similar al ya estudiado en el caso de la llamada waitQ, es decir, se 
utiliza para que la hebra padre espera a que la hebra hijo finalice su 
ejecucion. 



Listado 1.11: Primitivas POSIX Pthreads 



# include <pthread.h> 

2 

int pthread_create (pthread_t *thread, 
const pthread_attr_t *attr, 
void * (*start_routine) (void *), 
void *arq) ; 

7 

int pthread_join (pthread_t thread, void **retval) ; 



El listado de codigo de la pagina siguiente muestra un ejemplo muy 
sencillo de uso de Pthreads en el que se crea un hilo adicional que tie- 
ne como objetivo realizar el sumatorio de todos los numeros inferiores 
o iguales a uno pasado como parametro. La funcion mi_hilo() (lineas 
[ 27-36) ) es la que realmente implementa la funcionalidad del hilo crea- 
do mediante pthread_create() (linea (IT)). El resultado se almacena en 
una variable definida globalmente. Para llevar a cabo la compilacion y 
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ejecucion de este ejemplo, es necesario enlazar con la biblioteca pth- 
reads: 

$ goc -lpthread thread_simple . o -o thread_simple 
$ . /thread_simple <valor> 

El resultado de la ejecucion de este programa para un valor, dado 
por linea de ordenes, de 7 sera el siguiente: 

$ Suma total : 28 . 



Listado 1.12: Ejemplo de uso de Pthreads 



#include <pthread.h> 
#include <stdio.h> 
3 #include <stdlib.h> 

4 

int suma; 

void *mi_hilo (void *valor) ; 

7 

8 int main (int argc, char *argv[] ) { 

9 pthread_t tid; 

10 pthread_attr_t attr; 

11 

12 if (argc != 2) { 

fprintf (stderr, "Uso: . /pthread <entero>\n" ) ; 
14 return -1; 

} 

16 

17 pthread_attr_init (Sattr) ; // Att predeterminados . 

18 // Crear el nuevo hilo. 

19 pthread_create ( &tid, &attr, mi_hilo, argv[l]); 

20 pthread_join (tid, NULL); // Esperar f inalizacion . 
21 

22 printf("Suma total: %d.\n", suma); 

23 

24 return 0 ; 

25 } 
26 

void *mi_hilo (void *valor) { 

28 int i, Is; 

29 Is = atoi (valor) ; 

30 i = 0, suma = 0; 
31 

while (i <= Is) 

33 suma += (i++) ; 

34 

35 pthread_exit (0) ; 

36 } 



1.2. Fundamentos de programacion concurrente 
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1.2. Fundamentos de programacion concu- 
rrente 



Multiprocesamiento 

Recuerde que en los SSOO 
actuates, un unlco procesa- 
dor es capaz de ejecutar mul- 
tiples hllos de manera simul- 
tanea. SI el computador es 
paralelo, entonces exlstiran 
multiples nucleos fisicos eje- 
cutando codigo en paralelo. 



Un proceso cooperativo es un proceso que puede verse afectado 
por otros procesos que se esten ejecutando. Estos procesos pueden 
compartir unicamente datos, intercambiados mediante algun meca- 
nismo de envio de mensajes o mediante el uso de archivos, o pueden 
compartir datos y codigo, como ocurre con los hilos o procesos ligeros. 

En cualquier caso, el acceso concurrente a datos compartidos pue- 
de generar inconsistencias si no se usa algun tipo de esquema que 
garantice la coherencia de los mismos. A continuacion, se discute esta 
problematica y se plantean brevemente algunas soluciones, las cuales 
se estudiaran con mas detalle en sucesivos capitulos. 



1.2.1. El problema del productor/consumidor 

Considere un buffer de tamafio limitado que se comparte por un 
proceso productor y otro proceso consumidor. Mientras el primero 
afiade elementos al espacio de almacenamiento compartido, el segun- 
do los consume. Evidentemente, el acceso concurrente a este buffer 
puede generar incosistencias de dichos datos a la hora de, por ejem- 
plo, modificar los elementos contenidos en el mismo. 

Suponga que tambien se mantiene una variable cont que se incre- 
menta cada vez que se anade un elemento al buffer y se decrementa 
cuando se elimina un elemento del mismo. Este esquema posibilita 
manejar buffer_size elementos, en lugar de uno menos si dicha pro- 
blematica se controla con dos variables in y out. 

Aunque el codigo del productor y del consumidor es correcto de 
manera independiente, puede que no funcione correctamente al ejecu- 
tarse de manera simultanea. Por ejemplo, la ejecucion concurrente 
de las operaciones de incremento y decremento del contador pueden 
generar inconsistencias, tal y como se aprecia en la figura 1.8, en la 
cual se desglosan dichas operaciones en instrucciones maquina. En 
dicha figura, el codigo de bajo nivel asociado a incrementar y decre- 
mentar el contador inicializado a 5, genera un resultado inconsistente, 
ya que esta variable tendria un valor final de 4, en lugar de 5. 

Este estado incorrecto se alcanza debido a que la manipulacion de 
la variable contador se realiza de manera concurrente por dos procesos 
independientes sin que exista ningun mecanismos de sincronizacion. 
Este tipo de situacion, en la que se produce un acceso concurrente 
a unos datos compartidos y el resultado de la ejecucion depende del 
orden de las instrucciones, se denomina condicion de carrera. Para 
evitar este tipo de situaciones se ha de garantizar que solo un proce- 
so pueda manipular los datos compartidos de manera simultanea, es 
decir, dichos procesos se han de sincronizar de algun modo. 

Este tipo de situaciones se producen constantemente en el ambito 
de los sistemas operativos, por lo que el uso de mecanismos de sincro- 
nizacion es critico para evitar problemas potenciales. 
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cont++ 



while (1) { 

// Produce en nextP. 
while (cont == N) ; 

// No hacer nada . 
buffer [in] = nextP; 
in = (in + 1) % N; 
cont++; 




r = cont 

r = r + 1 

i i 

cont = r 



cont- 



ra = cont 
r = r - 1 

2 2 

cont = r 



r = cont 
i 

r = r + 1 

1 i 

r = cont 

2 

r = r - 1 

2 2 

cont = r 



cont 



2 



Figura 1.8: Codigo para los procesos productor y consumidor. 



1.2.2. La seccion critica 

El segmento de codigo en el que un proceso puede modificar va- 
riables compartidas con otros procesos se denomina seccion critica 
(ver figura 1.9). Para evitar inconsistencias, una de las ideas que se 
plantean es que cuando un proceso esta ejecutando su seccion critica 
ningun otro procesos puede ejecutar su seccion critica asociada. 

El problema de la seccion critica consiste en disenar algun tipo de 
solucion para garantizar que los procesos involucrados puedan operar 
sin generar ningun tipo de inconsistencia. Una posible estructura para 
abordar esta problematica se plantea en la figura 1.9, en la que el 
codigo se divide en las siguientes secciones: 

■ Seccion de entrada, en la que se solicita el acceso a la seccion 
critica. 

■ Seccion critica, en la que se realiza la modificacion efectiva de 
los datos compartidos. 

■ Seccion de salida, en la que tipicamente se hara explicita la sa- 
lida de la seccion critica. 

■ Seccion restante, que comprende el resto del codigo fuente. 

Normalmente, la seccion de entrada servira para manipular algun 
tipo de mecanismo de sincronizacion que garantice el acceso exclusivo 
a la seccion critica de un proceso. Mientras tanto, la seccion de sa- 
lida servira para notificar, mediante el mecanismo de sincronizacion 
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do{ 



] 




} while (l); 

Figura 1.9: Estructura general de un proceso. 



correspondiente, la salida de la seccion critica. Este hecho, a su vez, 
permitira que otro proceso pueda acceder a su seccion critica. 

Cualquier solucion al problema de la seccion critica ha de satisfacer 
los siguientes requisitos: 

1. Exclusion mutua, de manera que si un proceso pi esta en su 
seccion critica, entonces ningun otro proceso puede ejecutar su 
seccion critica. 

2. Progreso, de manera que solo los procesos que no esten en su 
seccion de salida, suponiendo que ningun proceso ejecutase su 
seccion critica, podran participar en la decision de quien es el 
siguiente en ejecutar su seccion critica. Ademas, la toma de esta 
decision ha de realizarse en un tiempo limitado. 

3. Espera limitada, de manera que existe un limite en el numero 
de veces que se permite entrar a otros procesos a sus secciones 
criticas antes de que otro proceso haya solicitado entrar en su 
propia seccion critica (y antes de que le haya sido concedida) . 

Las soluciones propuestas deberian ser independientes del numero 
de procesos, del orden en el que se ejecutan las instrucciones maqui- 
nas y de la velocidad relativa de ejecucion de los procesos. 

Una posible solucion para N procesos seria la que se muestra en el 
siguiente listado de codigo. Sin embargo, esta solucion no seria valida 
ya que no cumple el principio de exclusion mutua, debido a que un 
proceso podria entrar en la seccion critica si se produce un cambio de 
contexto justo despues de la sentencia while (linea (Tj). 
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Listado 1.13: Solucion deficiente para N procesos 



int cerrojo = 0; 

2 

do { 

4 // SECCION DE ENTRADA 

while (cerrojo == 1); // No hacer nada. 
cerrojo = 1; 

7 // SECCION CRfTICA. 

8 // . . . 

9 // SECCION DE SALIDA. 

10 cerrojo = 0; 

11 // SECCION RESTANTE. 

12 } while (1) ; 



Otro posible planteamiento para dos procesos se podria basar en 
un esquema de alternancia entre los mismos, modelado mediante una 
variable booleana turn, la cual indica que proceso puede entrar en la 
seccion critica, es decir, si turn es igual a i, entonces el proceso pi 
podra entrar en su seccion critica [j == (i — 1)). 



Listado 1.14: Solucion 2 procesos mediante alternancia 



1 do { 

2 // SECCION DE ENTRADA 

while (turn != i) ; // No hacer nada. 

4 // SECCION CRfTICA. 

5 // . . . 

6 // SECCION DE SALIDA. 

7 turn = j; 

8 // SECCION RESTANTE. 
} while (1); 



El problema de esta solucion es que cuando pj abandona la seccion 
critica y ha modificado turn a i, entonces no puede volver a entrar en 
ella porque primero tiene que entrar p t . Este proceso podria seguir 
ejecutando su seccion restante, por lo que la condicion de progreso 
no se cumple. Sin embargo, la exclusion mutua si que se satisface. 

Otra posible solucion para la problematica de dos procesos podria 
consistir en hacer uso de un array de booleanos, originalmente inicia- 
lizados a. false, de manera que si flag[i] es igual a true, entonces el 
proceso p t esta preparado para acceder a su seccion critica. 

Aunque este planteamiento garantiza la exclusion mutua, no se sa- 
tisface la condicion de progreso. Por ejemplo, si p 0 establece su turno 
a true en la seccion de entrada y, a continuacion, hay un cambio de 
contexto, el proceso p\ puede poner a true su turno de manera que 
ambos se queden bloqueados sin poder entrar en la seccion critica. En 
otras palabras, la decision de quien entra en la seccion critica se pos- 
pone indeflnidamente, violando la condicion de progreso e impidiendo 
la evolucion de los procesos. 
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Listado 1.15: Solucion 2 procesos con array de booleanos 



1 do { 

2 // SECCION DE ENTRADA 

3 flag[i] = true; 

while (flag[j]); // No hacer nada. 

5 // SECCION CRITICA. 

6 // ... 

7 // SECCION DE SALIDA. 
flag[i] = false; 

9 // SECCION RESTANTE. 
10 (while (1) ; 




iQue ocurre si se invlerte el orden de las operaclones de la SE? 



Listado 1.16: Solucion 2 procesos con array de booleanos 



1 do { 

2 // SECCION DE ENTRADA 

while (flag[j]); // No hacer nada. 
flag[i] = true; 

5 // SECCION CRITICA. 

6 // SECCION DE SALIDA. 
flag[i] = false; 

8 // SECCION RESTANTE. 

9 } while (1); 



Esta solucion no cumpliria con el principio de exclusion mutua. 

ya que los dos procesos podrian ejecutar su seccion critica de manera 
concurrente. 



Solucion de Peterson (2 procesos) 

En este apartado se presenta una solucion al problema de la sin- 
cronizacion de dos procesos que se basa en el algoritmo de Peterson, 
en honor a su inventor, y que fue planteado en 1981. La solucion de 
Peterson se aplica a dos procesos que van alternando la ejecucion de 
sus respectivas secciones criticas y restantes. Dicha solucion es una 
mezcla de las dos soluciones propuestas anteriormente. 

Los dos procesos comparten tanto el array flag, que determina los 
procesos que estan listos para acceder a la seccion critica, como la 
variable turn, que sirve para determinar el proceso que accedera a su 
seccion critica. Esta solucion es correcta para dos procesos, ya que 
satisface las tres condiciones anteriormente mencionadas. 

Para entrar en la seccion critica, el proceso asigna true a Jlagli] y 
luego asigna a turn el valor j, de manera que si el proceso pj desea en- 
trar en su seccion critica, entonces puede hacerlo. Si los dos procesos 
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intentan acceder al mismo tiempo, a la variable turn se le asignaran 
los valores i y j (o viceversa) en un espacio de tiempo muy corto, pe- 
ro solo prevalecera una de las asignaciones (la otra se sobreescribira) . 
Este valor determinara que proceso accedera a la seccion critica. 



Listado 1.17: Solucidn 2 procesos; algoritmo de Peterson 



1 


do { 




2 


// SECCION DE ENTRADA 




3 


flag[i] = true; 




4 


turn = j; 




5 


while (flag[j] ss turn == j); 


//No hacer nada 


6 


// SECCION CRITICA. 




7 


// . . . 




8 


// SECCION DE SALIDA. 




9 


flagti] = false; 




10 


// SECCION RESTANTE. 




11 


} while (1); 





A continuacion se demuestra que si pi esta en su seccion critica, 
entonces p 2 no esta en la suya. 



1 . pi en SC 




(premisa) 


2. pi en SC — > flag[l]=true y (flag [2]= 


false o turn! =2) 


(premisa) 


3. flag[l]=true y (flag[2] =false o turn! 


=2) 


(MP 1,2) 


4. flag[2]=false o turn!=2 (A o B) 




(EC 3) 


Demostrando A 






5. flag[2]=false (premisa) 






6. f lag [2] =f alse — > p2 en SC (premisa) 






7. p2 en SR (p2 no SC) (MP 5,6) 






Demostrando B 






8 . turn= ! 2 


(premisa) 




9. flag[l]=true 


(EC 3) 




10. flag[l]=true y turn=l 


(IC 8,9) 




11. (flag[l]=true y turn=l) — > p2 en SE 


(premisa) 




12 . p2 en SE (p2 no SC) 


(MP 10,11) 





Solucion de Lamport (n procesos) 

El algoritmo para n procesos desarrollado por Lamport es una solu- 
cion general e independiente del mimero de procesos inicialmente con- 
cebida para entornos distribuidos. Los procesos comparten dos arrays, 
uno de booleanos denominado eleccion, con sus elementos inicializa- 
dos a false, y otro de enteros denominado num, con sus elementos 
inicializados a 0. 

Este planteamiento se basa en que si esta en la seccion critica y 
Pj intenta entrar, entonces pj ejecuta el segundo bucle while y detecta 
que num[i] ^ 0, garantizando asi la exclusion mutua. 
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Listado 1.18: Solucion n procesos; algoritmo de Lamport 



1 


do { 




2 


// SECCION DE ENTRADA 




3 


eleccion[i] = true; 




4 


num[i] = max (num [ 0 ] , ... 


, num[n 


5 


eleccion[i] = false; 




6 


for (j = 0; j < n; j++) 


{ 


7 


while (eleccion [ j ] ) ; 




8 
9 


while (numtj] != 0 && 

} 


(num[ j] , 


10 


// SECCION CRITICA. 




11 


// . . . 




12 


// SECCION DE SALIDA. 




13 


num[i] = 0; 




14 


// SECCION RESTANTE. 




15 


(while (1); 





Soluciones hardware 

En general, cualquier solucion al problema de la seccion critica se 
puede abstraer en el uso de un mecanismo simple basado en cerrojos. 
De este modo, las condiciones de carrera no se producirian, siempre 
y cuando antes de acceder a la seccion critica, un proceso adquirie- 
se el uso exclusivo del cerrojo, bloqueando al resto de procesos que 
intenten abrirlo. Al terminar de ejecutar la seccion critica, dicho ce- 
rrojo quedaria liberado en la seccion de salida. Este planteamiento se 
muestra de manera grafica en la figura 1.10. 

Evidentemente, tanto las operaciones de adquisicion y liberacion 
del cerrojo han de ser atomicas es decir, su ejecucion ha de produ- 
cirse en una unidad de trabajo indivisible. 

El problema de la seccion critica se podria solucionar facilmente 
deshabilitando las interrupciones en entornos con un unico procesa- 
dor. De este modo, seria posible asegurar un esquema basado en la 
ejecucion en orden de la secuencia actual de instrucciones, sin per- 
mitir la posibilidad de desalojo, tal y como se plantea en los kernels 
no apropiativos. Sin embargo, esta solucion no es factible en entornos 
multiprocesador, los cuales representan el caso habitual en la actua- 
lidad. 

Como ejemplo representative de soluciones hardware, una posibili- 
dad consiste en hacer uso de una instruccion swap, ejecutada de ma- 
nera atomica mediante el hardware correspondiente, como parte de la 
seccion de entrada para garantizar la condicion de exclusion mutua. 
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Listado 1.19: Uso de operaciones swap 



1 


do { 


2 


// SECCION DE ENTRADA 


3 


key = true; 


4 


while (key == true) 


5 


swap (Slock, skey) ; 


6 


// SECCION CRfTICA. 


7 


// . . . 


8 


// SECCION DE SALIDA. 


9 


lock = false; 


10 


// SECCION RESTANTE. 


11 


}while (1) ; 



do{ 



adquirir_cerrojo 






SECCI6N_CRIT,CA 



liberar_cerrojo 



SECCION_RESTANTE 



} while (l); 

Figura 1.10: Acceso a la seccion critica mediante un cerrojo. 



Consideraciones 

Las soluciones estudiadas hasta ahora no son, por lo general, le- 
gibles y presentan dificultadas a la hora de extenderlas a problemas 
mas generales en los que se manejen n procesos. 

Por otra parte, los procesos que intentan acceder a la seccion critica 
se encuentra en un estado de espera activa, normalmente modelado 
mediante bucles que comprueban el valor de una variable de manera 
ininterrumpida. Este planteamiento es muy ineficiente y no se puede 
acoplar en sistemas multiprogramados. 

La consecuencia directa de estas limitaciones es la necesidad de 
plantear mecanismos que sean mas sencillos y que sean independien- 
tes del numero de procesos que intervienen en un determinado pro- 
blema. 

1.2.3. Mecanismos basicos de sincronizacion 

En este apartado se plantean tres mecanismos de sincronizacion 
que se estudiaran con detalle en los capitulos 2, 3 y 4, respectivamen- 
te. Estos mecanismos son los semaforos, el paso de mensajes y los 
monitores. 



1.2. Fundamentos de programacion concurrente 



[23] 



Semaforos 

Un semaforo es un mecanismo de sincronizacion que encapsula 
una variable entera que solo es accesible mediante dos operaciones 
atomicas estandar: wait y signal. La inicializacion de este tipo abs- 
tracto de datos tambien se considera relevante para definir el com- 
portamiento inicial de una solucion. Recuerde que la modificacion del 
valor entero encapsulado dentro de un semaforo ha de modificarse 
mediante instrucciones atomicas, es decir, tanto wait como signal han 
de ser instrucciones atomicas. Tipicamente, estas operaciones se uti- 
lizaran para gestionar el acceso a la seccion critica por un numero 
indeterminado de procesos. 

La definicion de wait es la siguiente: 



Listado 1.20: Semaforos; definicion de wait 



wait (sem) { 

2 while (sem <= 0) ; //No hacer nada. 

3 sem--; 

4 } 



Por otra parte, la definicion de signal es la siguiente: 



Listado 1.21: Semaforos; definicion de signal 



1 signal (sem) { 

2 sem++; 

3 } 



A continuacion se enumeran algunas caracteristicas de los sema- 
foros y las implicaciones que tiene su uso en el contexto de la sincro- 
nizacion entre procesos. 

■ Solo es posible acceder a la variable del semaforo mediante wait 
o signal. No se debe asignar o comparar los valores de la variable 
encapsulada en el mismo. 

■ Los semaforos han de inicializarse con un valor no negativo. 

■ La operacion wait decrementa el valor del semaforo. Si este se 
hace negativo, entonces el proceso que ejecuta wait se bloquea. 

■ La operacion signal incrementa el valor del semaforo. Si el valor 
no era positive entonces se desbloquea a un proceso bloqueado 
previamente por wait. 

Estas caracteristicas tienen algunas implicaciones importantes. Por 
ejemplo, no es posible determinar a priori si un proceso que ejecuta 
wait se quedara bloqueado o no tras su ejecucion. Asi mismo, no es 
posible conocer si despues de signal se despertara algun proceso o no. 

Por otra parte, waity signal son mutuamente excluyentes, es decir, 
si se ejecutan de manera concurrente, entonces se ejecutaran secuen- 
cialmente y en un orden no conocido a priori. 
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do{ 




} while (l); 

Figura 1.11: Acceso a la section critica mediante un semaforo. 



Si el valor de un semaforo es positivo, dicho valor representa el 
numero de procesos que pueden decrementarlo a traves de wait sin 
quedarse bloqueados. Por el contrario, si su valor es negative repre- 
senta el numero de procesos que estan bloqueados. Finalmente, un 
valor igual a cero implica que no hay procesos esperando, pero una 
operacion wait hara que un proceso se bloquee. 

Los semaforos se suelen clasificar en contadores y binarios, en fun- 
cion del rango de valores que tome las variables que encapsulan. Un 
semaforo binario es aquel que solo toma los valores 0 6 1 y tambien se 
conoce como cerrojo mutex (mutual exclusion). Un semaforo contador 
no cumple esta restriccion. 

Las principales ventajas de los semaforos con respecto a otro tipo 
de mecanismos de sincronizacion se pueden resumir en las tres si- 
guientes: i) simplicidad, ya que facilitan el desarrollo de soluciones de 
concurrencia y son simples, ii) correctitud, ya que los soluciones son 
generalmente limpias y legibles, siendo posible llevar a cabo demostra- 
ciones formales, iii) portabilidad, ya que los semaforos son altamente 
portables en diversas plataformas y sistemas operativos. 

La figura 1.12 muestra una posible solucion al problema del pro- 
ductor/consumidor. Tipicamente los semaforos se utilizan tanto para 
gestionar el sincronismo entre procesos como para controlar el acceso 
a fragmentos de memoria compartida, como por ejemplo el buffer de 
productos. 

Esta solucion se basa en el uso de tres semaforos: 

■ mutex se utiliza para proporcionar exclusion mutua para el ac- 
ceso al buffer de productos. Este semaforo se inicializa a 1. 

■ empty se utiliza para controlar el numero de huecos vacios del 
buffer. Este semaforo se inicializa a n. 

■ full se utiliza para controlar el numero de huecos llenos del bu- 
ffer. Este semaforo se inicializa a 0. 
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r. 



while (1) { 

// Produce en nextP. 
wait (empty) ; 
wait (mutex) ; 

// Guarda nextP en buffer, 
signal (mutex) ; 
signal ( f ull ) ; 



Figura 1.12: Procesos productor y consumidor sincronlzados mediante un semaforo. 



En el capitulo 2 se discutira mas en detalle el concepto de semaforo 
y su utilizacion en problemas clasicos de sincronizacion. Ademas, se 
estudiara una posible implementacion utilizando las primitivas pro- 
porcionadas por el estandar POSIX. 



Paso de mensajes 

El mecanismo de paso de mensajes es otro esquema que permite 
la sincronizacion entre procesos. La principal diferencia con respecto 
a los semaforos es que permiten que los procesos se comuniquen sin 
tener que recurrir al uso de varibles de memoria compartida. 

En los sistemas de memoria compartida hay poca cooperacion del 
sistema operativo, estan orientados al proceso y pensados para en- 
tornos centralizados, y es tarea del desarrollador establecer los meca- 
nismos de comunicacion y sincronizacion. Sin embargo, los sistemas 
basados en el paso de mensajes son validos para entornos distribui- 
dos, es decir, para sistemas con espacios logicos distintos, y facilitar 
los mecanismos de comunicacion y sincronizacion es labor del sistema 
operativo, sin necesidad de usar memoria compartida. 

El paso de mensajes se basa en el uso de los dos primitivas siguien- 
tes: 

■ send, que permite el envio de informacion a un proceso. 




receive, que permite la recepcion de informacion por parte de un 
proceso. 
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Figura 1.13: Esquema grafico del mecanismo de paso de mensajes. 

Ademas, es necesario un canal de comunicacion entre los propios 
procesos para garantizar la entrega y recepcion de los mensajes. 

Resulta importante distinguir entre varios tipos de comunicacion, 

en base a los conceptos directa/indirecta y simetrica/asimetrica. En 
esencia, la comunicacion directa implica que en el mensaje se cono- 
cen, implicitamente, el receptor y el receptor del mismo. Por el con- 
trario, la comunicacion indirecta se basa en el uso de buzones. La 
comunicacion simetrica se basa en que el receptor conoce de quien 
recibe un mensaje. Por el contrario, en la comunicacion asimetrica el 
receptor puede recibir de cualquier proceso. 

El siguiente listado de codigo muestra un ejemplo basico de sin- 
cronizacion entre dos procesos mediante el paso de mensajes. En el 
capitulo 3 se discutira mas en detalle el concepto de paso de mensajes 
y su utilizacion en problemas clasicos de sincronizacion. Ademas, se 
estudiara una posible implementacion utilizando las primitivas que el 
estandar POSIX proporciona. 



Listado 1.22: Sincronizacion mediante paso de mensajes 



1 // Proceso 1 
while ( 1 ) { 

3 // Trabajo previo pi... 
send (' *' , P2) 

5 // Trabajo restante pi . . . 

6 } 
7 

8 // Proceso 2 
while ( 1 ) { 

10 // Trabajo previo p2 . . . 

11 receive (Smsg, PI) 

12 // Trabajo restante p2 . . . 
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Condiciones 



Datos 
compartidos 



Operaciones 



Codigo 
inicializacion 



Figura 1.14: Esquema grafico del uso de un monitor. 



Monitores 



Aunque los semaforos tienen ciertas ventajas que garantizan su 
exito en los problemas de sincronizacion entre procesos, tambien su- 
fren ciertas debilidades. Por ejemplo, es posible que se produzcan erro- 
res de temporizacion cuando se usan. Sin embargo, la debilidad mas 
importante reside en su propio uso, es decir, es facil que un progra- 
mador cometa algun error al, por ejemplo, intercambiar erroneamente 
un wait y un signal 

Con el objetivo de mejorar los mecanismos de sincronizacion y evi- 
tar este tipo de problematica, en los ultimos anos se han propuesto 
soluciones de mas alto nivel, como es el caso de los monitores. 

Basicamente, un tipo monitor permite que el programador defina 
una serie de operaciones publicas sobre un tipo abstracto de datos que 
gocen de la caracteristica de la exclusion mutua. La idea principal esta 
ligada al concepto de encapsulacion, de manera que un procedimiento 
definido dentro de un monitor solo puede acceder a las variables que 
se declaran como privadas o locales dentro del monitor. 

Esta estructura garantiza que solo un proceso este activo cada vez 
dentro del monitor. La consecuencia directa de este esquema es que el 
programador no tiene que implementar de manera explicita esta res- 
triccion de sincronizacion. Esta idea se traslada tambien al concepto 
de variables de condicion. 

En esencia, un monitor es un mecanismo de sincronizacion de mas 
alto nivel que, al igual que un cerrqjo, protege la seccion critica y ga- 
rantiza que solamente pueda existir un hilo activo dentro de la misma. 
Sin embargo, un monitor permite suspender un hilo dentro de la sec- 
cion critica posibilitando que otro hilo pueda acceder a la misma. Este 
segundo hilo puede abandonar el monitor, liberandolo, o suspenderse 
dentro del monitor. De cualquier modo, el hilo original se despierta y 
continua su ejecucion dentro del monitor. Este esquema es escalable 
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a multiples hilos, es decir, varios hilos pueden suspenderse dentro de 
un monitor. 

Los monitores proporcionan un mecanismo de sincronizacion mas 
flexible que los cerrojos, ya que es posible que un hilo compruebe una 
condicion y, si esta es falsa, el hijo se pause. Si otro hilo cambia dicha 
condicion, entonces el hilo original continua su ejecucion. 

El siguiente listado de codigo muestra el uso del mecanismo de tipo 
monitor que el lenguaje Java proporciona para la sincronizacion de 
hebras. En Java, cualquier objeto tiene asociado un cerrojo. Cuando 
un metodo se declara como synchronized, la llamada al metodo implica 
la adquisicion del cerrojo, evitando el acceso concurrente a cualquier 
otro metodo de la clase que use dicha declaracion. 

En el ejemplo que se expone a continuacion, el monitor se utiliza 
para garantizar que el acceso y la modificacion de la variable de clase 
_edad solo se haga por otro hilo garantizando la exclusion mutua. 
De este modo, se garantiza que no se produciran inconsistencias al 
manipular el estado de la clase Persona. 



Listado 1.23: Sincronizacion con monitores en Java 



class Persona { 

private int _edad; 

public Persona (int edad) { 

4 _edad = edad; 

5 } 

public synchronized void setEdad (int edad) { 
_edad = edad; 

8 } 

public synchronized int getEdad ( ) { 

10 return _edad; 

11 1 

12 } 



1.2.4. Interbloqueos y tratamiento del deadlock 

En un entorno multiprogramado, los procesos pueden competir por 
un numero limitado de recursos. Cuando un proceso intenta adquirir 
un recurso que esta siendo utilizado por otro proceso, el primero pasa 
a un estado de espera, hasta que el recurso quede libre. Sin embargo, 
puede darse la situacion en la que un proceso esta esperando por un 
recurso que tiene otro proceso, que a su vez esta esperando por un ter- 
cer recurso. A este tipo de situaciones se les denomina interbloqueos 
o deadlocks. 

La figura 1.15 muestra un ejemplo de interbloqueo en el que el pro- 
ceso pi mantiene ocupado el recurso n y esta a la espera del recurso 
r 2 , el cual esta ocupado por el proceso p 2 . Al mismo tiempo, p 2 esta a 
la espera del recurso r\. Debido a que los dos procesos necesitan los 
dos recursos para completar sus tareas, ambos se encuentran en una 
situacion de interbloqueo a la espera del recurso necesario. 
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a 



Un conjunto de procesos estara en un estado de interbloqueo 
cuando todos los procesos del conjunto esten esperando a que 
se produzca un suceso que solo puede produclrse como resul- 
tado de la actlvidad de otro proceso del conjunto [12]. 



El modelo de sistema con el que se trabajara a continuacion es 
una abstraccion de la problematica de los sistemas operativos moder- 
nos, los cuales estan compuestos de una serie de recursos por los que 
compiten una serie de procesos. En esencia, los recursos se clasifican 
en varios tipos y cada uno de ellos tiene asociado una serie de instan- 
cias. Por ejemplo, si el procesador tiene dos nucleos de procesamiento, 
entonces el recurso procesador tiene dos instancias asociadas. 



©La sollcltud y liberation de recursos se traducen en llamadas 
al sistema. Un ejemplo representativo seria la dupla cdlocateQ- 
freeO. 



Tipicamente, un proceso ha de solicitar un recurso antes de uti- 
lizarlo y ha de liberarlo despues de haberlo utilizado. En modo de 
operacion normal, un proceso puede utilizar un recurso siguiendo la 
siguiente secuencia: 
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Figura 1.16: Condition de espera circular con dos procesos y dos recursos. 

1. Solicitud: si el proceso no puede obtenerla inmediatamente, ten- 
dra que esperar hasta que pueda adquirir el recurso. 

2. Uso: el proceso ya puede operar sobre el recurso. 

3. Liberacion: el proceso libera el recurso. 

Los interbloqueos pueden surgir si se dan, de manera simultanea, 
las cuatro condiciones de Coffman [12]: 

1. Exclusion mutua: al menos un recurso ha de estar en modo no 
compartido, es decir, solo un proceso puede usarlo cada vez. En 
otras palabras, si el recurso esta siendo utilizado, entonces el 
proceso que desee adquirirlo tendra que esperar. 

2. Retencion y espera: un proceso ha de estar reteniendo al menos 
un recurso y esperando para adquirir otros recursos adicionales, 
actualmente retenidos por otros procesos. 

3. No apropiacion: los recursos no pueden desalojarse, es decir, 
un recurso solo puede ser liberado, de manera voluntaria, por el 
proceso que lo retiene despues de finalizar la tarea que estuviera 
realizando. 

4. Espera circular: ha de existir un conjunto de procesos en compe- 
ticion P = {po,p\, ...,p n -i} de manera que p 0 espera a un recurso 
retenido por p lt px a un recurso retenido por p 2 , y p n -i a un 
recurso retenido por p 0 . 

Todas estas condiciones han de darse por separado para que se 
produzca un interbloqueo, aunque resulta importante resaltar que 
existen dependencias entre ellas. Por ejemplo, la condicion de espe- 
ra circular implica que se cumpla la condicion de retencion y espera. 

Grafos de asignacion de recursos 

Los interbloqueos se pueden definir de una forma mas precisa, fa- 
cilitando ademas su analisis, mediante los grafos de asignacion de re- 
cursos. El conjunto de nodos del grafo se suele dividir en dos subcon- 
juntos, uno para los procesos activos del sistema P = {po,pi, ...,p n -i} y 
otro formado por los tipos de recursos del sistema R = {r 1 ,r 2 , ...,r n _i}. 
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1 3 




R R 

2 4 

Figura 1.17: Ejemplo de grafo de asignacion de recursos. 



Por otra parte, el conjunto de aristas del grafo dirigido permite esta- 
blecer las relaciones existentes entre los procesos y los recursos. Asi, 
una arista dirigida del proceso p { al recurso r 2 - significa que el proceso 
Pi ha solicitado una instancia del recurso r 3 . Recuerde que en el mo- 
delo de sistema planteado cada recurso tiene asociado un numero de 
instancias. Esta relacion es una arista de solicitud y se representa 
como p l rj . 

Por el contrario, una arista dirigida del recurso r 0 al proceso pi 
significa que se ha asignado una instancia del recurso r 3 - al proceso pi. 
Esta arista de asignacion se representa como r 3 ->• p { . La figura 1.17 
muestra un ejemplo de grafo de asignacion de recursos. 

Los grafos de asignacion de recursos que no contienen ciclos no 
sufren interbloqueos. Sin embargo, la presencia de un ciclo puede ge- 
nerar la existencia de un interbloqueo, aunque no necesariamente. Por 
ejemplo, en la parte izquierda de la figura 1. 18 se muestra un ejemplo 
de grafo que contiene un ciclo que genera una situacion de interblo- 
queo, ya que no es posible romper el ciclo. Note como se cumplen las 
cuatro condiciones de Cqffman. 

La parte derecha de la figura 1.18 muestra la existencia de un ciclo 
en un grafo de asignacion de recursos que no conduce a un interblo- 
queo, ya que si los procesos p 2 o p 4 finalizan su ejecucion, entonces el 
ciclo se rompe. 
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Figura 1.18: Grafos de asignacion de recursos con deadlock (izquierda) y sin deadlock 
(derecha). 



Tratamiento del deadlock 

Desde un punto de vista general, existen tres formas para llevar a 
cabo el tratamiento de los interbloqueos o deadlocks: 

1. Impedir o evitar los interbloqueos, sin que se produzcan. 

2. Detectar y recuperarse de los interbloqueos, es decir, tener me- 
canismos para identificarlos y, posteriormente, solventarlos. 

3. Ignorar los interbloqueos, es decir, asumir que nunca van a ocu- 
rrir en el sistema. 



La figura 1.19 muestra un esquema general con las distintas alter - 
nativas existentes a la hora de tratar los interbloqueos. A continuacion 
se discutiran los fundamentos de cada una de estas alternativas, plan- 
teando las ventajas y desventajas que tienen. 

Con el objetivo de evitar interbloqueos, el sistema puede plantear 
un esquema de prevencion o evasion de interbloqueos. Tipicamente, 
las tecnicas de prevencion de interbloqueos se basan en asegurar que 
al menos una de las condiciones de Cqffman no se cumpla. Para ello, 
estos metodos evitan los interbloqueos limitando el modo en el que los 
procesos realizan las solicitudes sobre los recursos. 

Por otra parte, la evasion de interbloqueos se basa en un esquema 
mas dinamico que gira en torno a la solicitud de mas informacion re- 
lativa a las peticiones de recursos por parte de los procesos. Esta idea 
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Metodos tratamiento deadlock 
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Figura 1.19: Diagrama general con distintos metodos para tratar los interbloqueos. 



se suele denominar polftica de asignacion de recursos. Un ejemplo 
tipico consiste en especificar el numero maximo de instancias que un 
proceso necesitara para cumplir una tarea. 

Si un sistema no usa un mecanismo que evite interbloqueos, otra 
opcion consiste en intentar detectarlos y, posterior mente, tratar de 
recuperarse de ellos. 

En la practica, todos estos metodos son costosos y su aplicacion 
no supone, generalmente, una gran ventaja con respecto al beneficio 
obtenido para solventar una situacion de interbloqueo. De hecho, los 
sistemas operativos modernos suelen basarse en la hipotesis de que 
no se produciran interbloqueos, delegando en el programador esta pro- 
blematica. Esta aproximacion se denomina comunmente algoritmo del 
avestruz, y es el caso de los sistemas operativos UNIX y Windows. 




En determinadas situaciones es deseable ignorar un problema 
por completo debido a que el beneficio obtenido al resolverlo es 
menor que la generaclon de un poslble fallo. 
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Prevencion de interbloqueos 

Como se ha comentado anteriormente, las tecnicas de prevencion 
de interbloqueos se basan en garantizar que algunas de las cuatro 
condiciones de Cqffman no se cumplan. 

La condicion de exclusion mutua esta asociada a la propia natura- 
leza del recurso, es decir, depende de si el recurso se puede compartir 
o no. Los recursos que pueden compartirse no requieren un acceso 
mutuamente excluyente, como por ejemplo un archivo de solo lectu- 
ra. Sin embargo, en general no es posible garantizar que se evitara un 
interbloqueo incumpliendo la condicion de exclusion mutua, ya que 
existen recursos, como por ejemplo una impresora, que por naturale- 
za no se pueden compartir. . 

La condicion de retener y esperar se puede negar si se garantiza 
de algun modo que, cuando un proceso solicite un recurso, dicho pro- 
ceso no este reteniendo ningun otro recurso. Una posible solucion a 
esta problematica consiste en solicitar todos los recursos necesarios 
antes de ejecutar una tarea. De este modo, la politica de asignacion de 
recursos decidira si asigna o no todo el bloque de recursos necesarios 
para un proceso. Otra posible opcion seria plantear un protocolo que 
permitiera a un proceso solicitar recursos si y solo si no tiene ninguno 
retenido. 



@iQue desventajas presentan los esquemas planteados para evi- 
tar la condicion de retener y esperar? 



Estos dos planteamientos presentan dos desventajas importantes: 
i) una baja tasa de uso de los recursos, dado que los recursos pueden 
asignarse y no utilizarse durante un largo periodo de tiempo, y ii) el 
problema de la inanicion, ya que un proceso que necesite recursos 
muy solicitados puede esperar de forma indefinida. 

La condicion de no apropiacion se puede incumplir desalojando 
los recursos que un proceso re tiene en el caso de solicitar otro recur- 
so que no se puede asignar de forma inmediata. Es decir, ante una 
situacion de espera por parte de un proceso, este liberaria los recur- 
sos que retiene actualmente. Estos recursos se afiadirian a la lista de 
recursos que el proceso esta esperando. Asi, el proceso se reiniciara 
cuando pueda recuperar sus antiguos recursos y adquirir los nuevos, 
solucionando asi el problema planteado. 

Este tipo de protocolos se suele aplicar a recursos cuyo estado pue- 
da guardarse y restaurarse facilmente, como los registros de la CPU o 
la memoria. Sin embargo, no se podria aplicar a recursos como una 
impresora. 

Finalmente, la condicion de espera circular se puede evitar esta- 
bleciendo una relacion de orden completo a todos los tipos de recursos. 
De este modo, al mantener los recursos ordenados se puede definir un 
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Peticiones de recursos 
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Figura 1.20: Diagrama general de una politica de evasion de interbloqueos. 



protocolo de asignacion de recursos para evitar la espera circular. Por 
ejemplo, cada proceso solo puede solicitar recursos en orden creciente 
de enumeracion, es decir, solo puede solicitar un recurso mayor al res- 
to de recursos ya solicitados. En el caso de necesitar varias instancias 
de un recurso, se solicitarian todas a la vez. Recuerde que respetar la 
politica de ordenacion planteada es responsabilidad del programador. 



Evasion de interbloqueos 

La prevencion de interbloqueos se basa en restringir el modo en 
el que se solicitan los recursos, con el objetivo de garantizar que al 
menos una de las cuatro condiciones se incumpla. Sin embargo, este 
planteamiento tiene dos consecuencias indeseables: la baja tasa de 
uso de los recursos y la reduccion del rendimiento global del sistema. 

Una posible alternativa consiste en hacer uso de informacion rela- 
tiva a como se van a solicitar los recursos. De este modo, si se dispone 
de mas informacion, es posible plantear una politica mas completa que 
tenga como meta la evasion de potenciales interbloqueos en el futuro. 
Un ejemplo representativo de este tipo de informacion podria ser la 
secuencia completa de solicitudes y liberaciones de recursos por parte 
de cada uno de los procesos involucrados. 

Las alternativas existentes de evasion de interbloqueos varian en 
la cantidad y tipo de informacion necesaria. Una solucion simple se 
basa en conocer unicamente el numero maximo de recursos que un 
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proceso puede solicitar de un determinado recurso. El algoritmo de 
evasion de interbloqueos examinara de manera dinamica el estado de 
asignacion de cada recurso con el objetivo de que no se produzca una 
espera circular. 

En este contexto, el concepto de estado seguro se define como 
aquel en el que el sistema puede asignar recursos a cada proceso (has- 
ta el maximo definido) en un determinado orden sin que se produzca 
un interbloqueo. 

A continuacion se describe el denominado algoritmo del banque- 
ro 3 . En esencia, este algoritmo se basa en que cuando un proceso 
entra en el sistema, este ha de establecer el numero maximo de ins- 
tancias de cada tipo de recurso que puede necesitar. Dicho numero no 
puede exceder del maximo disponible en el sistema. La idea general 
consiste en determinar si la asignacion de recursos dejara o no al sis- 
tema en un estado seguro. Si es asi, los recursos se asigna. Si no lo es, 
entonces el proceso tendra que esperar a que otros procesos liberen 
sus recursos asociados. 

La figura 1.20 muestra un diagrama basado en la aplicacion de una 
politica de evasion de interbloqueos mediante el algoritmo del banque- 
ro y la compracion de estados seguros en el sistema. 

Para implementar el algoritmo del banquero, es necesario hacer uso 
de varias estructuras de datos: 

■ Available, un vector de longitud m, definido a nivel global del 
sistema, que indica el numero de instancias disponibles de cada 
tipo de recurso. Si available[j] = k, entonces el sistema dispone 
actualmente de k instancias del tipo de recurso rj . 

■ Max, una matriz de dimensiones nxm que indica la demanda ma- 
xima de cada proceso. Si max[i][j] = k, entonces el proceso pi 
puede solicitar, como maximo, k instancias del tipo de recurso rj. 

■ Allocation, una matriz de dimensiones nxm que indica el numero 
de instancias de cada tipo de recurso asignadas a cada proceso. 
Si allocation[i}[j] = k, entonces el proceso pi tiene actualmente 
asignadas k instancias del recurso rj . 

■ Need, una matriz de dimensiones nxm que indica la necesidad 
restante de recursos por parte de cada uno de los procesos. Si 
neec?[i][j] = k, entonces el proceso p, puede que necesite k instan- 
cias adicionales del recurso rj. need[i][j] = max[i][j]—allocation[i][j]. 

El algoritmo que determina si las solicitudes pueden concederse de 
manera segura es el siguiente. Sea requesU el vector de solicitud para 
Pi. Ej. requesU = [0,3, 1]. Cuando p l hace una solicitud de recursos se 
realizan las siguientes acciones: 

1. Si requesU < needi, ir a 2. Si no, generar condicion de error, ya 
que se ha excedido el cantidad maxima de recursos. 



3 E1 origen de este nombre esta en su utilization en slstemas bancarios. 
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2. Si requesti < available, ir a 3. Si no, p l tendra que esperar a que 
se liberen recursos. 

3. Realizar la asignacion de recursos. 

a) available = available — requesti 

b) allocatiotii — allocation + requesti 

c) needi = needi — requesti 

4. Si el estado resultante es seguro, modificar el estado. Si no, res- 
taurar el estado anterior, pi esperara a que se le asignen los re- 
cursos requesti. 

El algoritmo que determina si un estado es seguro es el siguiente. 
Sean work y finish dos vectores de longitud m y n, inicializados del 
siguiente modo: work = available y finish[i] = falseii e {0, 1, ...,n- 1}. 

1. Hallar i (si no existe, ir a 3) tal que 

a) finish[i] == false 

b) needi < work 

2. work = work + allocation, finish[i] — true, ir a 1. 

3. Si finish[i] == true,Vi e {0,1,..., n - 1}, entonces el sistema esta 
en un estado seguro. 

A continuacion se plantea un ejercicio sobre la problematica aso- 
ciada al algoritmo del banquero y a la comprobacion de estado seguro. 
Considere el siguiente estado de asignacion de recursos en un sistema: 
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10 0 0 
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Asi mismo, available = [1, 5, 2, 0] 

Si se utiliza un mecanismo de evasion del interbloqueo, ^,esta el 
sistema en un estado seguro? 

En primer lugar, se hace uso de dos vectores: i) work = [1,5,2,0] y 
ii) finish = [/, /, /, /, /] y se calcula la necesidad de cada uno de los 
procesos {max — allocation): 

■ need 0 = [0, 0, 0, 0] 

■ needi = [0, 7, 5,0] 

■ need 2 = [1,0,0,2] 
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■ need 3 = [0, 0, 2, 0] 

■ needi = [0, 6, 4, 2] 

A continuacion, se analiza el estado de los distintos procesos. 

■ p 0 : need 0 < work = [0, 0, 0, 0] < [1, 5, 2, 0]; finish[0] = f. 

• work = [1, 5, 2, 0] + [0, 0, 1, 2] = [1, 5, 3, 2] 

• finish = [v, f, f, /, f] 

■ p\. needi > work = [0, 7, 5, 0] > [1, 5, 3, 2] 

■ p 2 : need 2 < work = [1, 0, 0, 2] < [1, 5, 3, 2]; finish[2] = f. 

• work = [1, 5, 3, 2] + [1, 3, 5, 4] = [2, 8, 8, 6] 

• finish = [v,f,v,f,f] 

■ p\\ needi < work = [0, 7, 5, 0] < [2, 8, 8, 6]; finish[l] = f. 

• work = [2, 8, 8, 6] + [1, 0, 0, 0] = [3, 8, 8, 6] 

• finish = [v,v,v, f, f] 

■ ps'. needs < work = [0, 0, 2, 0] < [3, 8, 8, 6]; finish[3] = f. 

• work = [3, 8, 8, 6] + [0, 6, 3, 2] = [3, 14, 11, 8] 

• finish=[v,v,v,v,f] 

■ p 4 : needi < work = [0,6,4,2] < [3, 14, 11, 8]; finish[4] = f. 

• work = [3, 14, 11, 8] + [0, 0, 1, 4] = [3, 14, 12, 12] 

• finish = [v, v, v, v, v] 

Por lo que se puede afirmar que el sistema se encuentra en un 
estado seguro. 

Si el proceso pi solicita recursos por valor de [0, 4, 2, 0], ^puede aten- 
derse con garantias de inmediato esta peticion? 

En primer lugar habria que aplicar el algoritmo del banquero para 
determinar si dicha peticion se puede conceder de manera segura. 

1. request^ < need! «-> [0, 4, 2, 0] < [0, 7, 5, 0] 

2. requesti < available! o [0,4,2,0] < [1,5,2,0] 

3. Asignacion de recursos. 

a) available — available — requesti = [1> 5, 2, 0] — [0, 4, 2, 0] = [1, 1, 0, 0] 

b) allocation — allocation! + requesti = [1,0,0,0] + [0,4,2,0] = 
[1,4,2,0] 

c) need! = need! - requesti = [0, 7, 5, 0] - [0, 4, 2, 0] = [0, 3, 3, 0] 

4. Comprobacion de estado seguro. 
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En primer lugar, se hace uso de dos vectores: i) work = [1, 1,0,0] y 
ii) finish = [/, /, /, /, /] y se calcula la necesidad de cada uno de los 
procesos {max — allocation): 

■ need 0 = [0, 0, 0, 0] 

■ needx = [0,3,3,0] 

■ need 2 = [1,0,0,2] 

■ needs = [0,0,2,0] 

■ needi = [0, 6, 4, 2] 

A continuacion, se analiza el estado de los distintos procesos. 

■ p Q : need 0 < work = [0,0,0,0] < [1, 1, 0, 0]; finish[0] = f. 

• work = [1, 1, 0, 0] + [0, 0, 1, 2] = [1, 1, 1, 2] 

• finish = [v, /, /, /, /] 

■ Pl : needx > work = [0,3,3,0] > [1, 1, 1,2] 

■ p 2 : need 2 < work = [1,0,0,2] < [1, 1, 1, 2]; finish[2] = f. 

• work = [1, 1, 1, 2] + [1, 3, 5, 4] = [2, 4, 6, 6] 

• finish = [v, /, v, /, /] 

■ Pl : needx < work = [0, 3, 3, 0] < [2, 4, 6, 6] ; finish[l] = f. 

• work = [2, 4, 6, 6] + [1, 4, 2, 0] = [3, 8, 8, 6] 

• finish = [v, v, v, f, f] 

■ ps'. needs < work = [0, 0, 2, 0] < [3, 8, 8, 6]; finish[3] = f. 

• work = [3, 8, 8, 6] + [0, 6, 3, 2] = [3, 14, 11, 8] 

• finish = [v, v, v, v, f] 

■ Pi : needi < work = [0, 6, 4, 2] < [3, 14, 11, 8]; finish[4] = f. 

• work = [3, 14, 11, 8] + [0, 0, 1, 4] = [3, 14, 12, 12] 

• finish = [v, v, v, v, v] 

Se puede afirmar que el sistema se encuentra en un estado seguro 
despues de la nueva asignacion de recursos al proceso Pl . 
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1.3. Fundamentos de tiempo real 



El rango de aplicacion de los dispositivos electronicos, incluyen- 
do los ordenadores, ha crecido exponencialmente en los ultimos anos. 
Uno de estos campos esta relacionado con las aplicaciones de tiempo 
real, donde es necesario llevar a cabo una determinada funcionalidad 
atendiendo a una serie de restricciones temporales que son esenciales 
en relacion a los requisitos de dichas aplicaciones. Por ejemplo, consi- 
dere el sistema de control de un coche. Este sistema ha de ser capaz 
de responder a determinadas acciones en tiempo real. 

Es importante resaltar que las aplicaciones de tiempo real tienen 
caracteristicas que los hacen particulares con respecto a otras aplica- 
ciones mas tradicionales de procesamiento de informacion. A lo largo 
del tiempo han surgido herramientas y lenguajes de programacion es- 
pecialmente disenados para facilitar su desarrollo. 

1.3.1. t,Que es un sistema de tiempo real? 

Segun el Oxford Dictionary of Computing, un sistema de tiempo real 
se define como «cualquier sistema en el que el tiempo en el que se pro- 
duce la salida es significativo. Esto generalmente es porque la entrada 
corresponde a algun movimiento en el mundofisico, y la salida esta rela- 
cionada con dicho movimiento. El intervalo entre el tiempo de entrada y 
el de salida debe ser lo suficientemente pequeno para una temporalidad 
aceptable». 

El concepto de temporalidad resulta esencial en un sistema de 
tiempo real, ya que marca su diferencia en terminos de requisitos con 
respecto a otro tipo de sistemas. 

Como ejemplo representativo, considera la situacion en la que un 
usuario interactua con un sistema de venta de entradas de cine. Ante 
una peticion de compra, el usuario espera que el sistema responda en 
un intervalo de tiempo razonable (quizas no mas de cinco segundos). 
Sin embargo, una demora en el tiempo de respuesta por parte del 
sistema no representa una situacion critica. 



o 



Un sistema de tiempo real no ha de ser necesariamente muy 
rapido, sino que ha de responder en un intervalo de tiempo 
previamente definido, es decir, ha de mantener un comporta- 
miento determinista. 



STR 



Los sistemas de tiempo real 
tambien se conocen como 
sistemas empotrados o em- 
bebidos, debido a su integra- 
cion en el propio dispositivo 
que proporciona una deter- 
minada funcionalidad. 




Figura 1.21: Probando un 
sistema de airbag en un he- 
licoptero OH-58D (fuente Wi- 
kipedia) . 



Por el contrario, considere el sistema de airbag de un coche, el 
cual esta controlado por un microprocesador. Ante una situacion de 
emergencia, como por ejemplo un choque con otro vehiculo, el sistema 
ha de garantizar una respuesta en un intervalo de tiempo acotado 

y perfectamente definido con el objetivo de garantizar una respuesta 
adecuada del sistema de seguridad. Este si es un ejemplo representa- 
tivo de sistema de tiempo real. 
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Correctitud STR 



La correctitud de un sistema 
de tiempo real no solo depen- 
de de la correctitud del resul- 
tado obtenido, sino tambien 
del tiempo empleado para ob- 
tenerlo. 



Desde el punto de vista del diseno, los sistemas de tiempo real se 
suelen clasificar en estrictos (hard) y no estrictos [soft] [3], depen- 
diendo si es absolutamente necesario que la respuesta se produzca 
antes de un tiempo limite (deadline) especificado o no, respectivamen- 
te. En el caso de los sistemas de tiempo real no estrictos, el tiempo de 
respuesta sigue siendo muy importante pero el sistema garantiza su 
funcionamiento incluso cuando este tiempo limite se incumple ocasio- 
nalmente. 

Tradicionalmente, los sistemas de tiempo real se han utilizado para 
el control de procesos, la fabricacion y la comunicacion. No obstante, 
este tipo de sistemas tambien se utilizan en un contexto mas general 
con el objetivo de proporcionar una monitorizacion continua de un 
determinado entorno fisico. 

En el diseno y desarrollo de sistemas de tiempo real son esencia- 
les aspectos relacionados con la programacion concurrente, la plani- 
ficacion en tiempo real y la fiabilidad y la tolerancia a fallos. Estos 
aspectos seran cubiertos en capitulos sucesivos. 

Caracteristicas de un sistema de tiempo real 

El siguiente listado resume las principales caracteristicas que un 
sistema de tiempo real puede tener [3]. Idealmente, un lenguaje de 
programacion o sistema operativo que se utilice para el desarrollo de 
un sistema de tiempo real deberia proporcionar dichas caracteristicas. 




Figura 1.22: Distintos com- 
ponentes del hardware in- 
terno de un modem/router 
de ADSL (fuente Wikipedia). 



Complejidad, en terminos de tamano o numero de lineas de co- 
digo fuente y en terminos de variedad de respuesta a eventos del 
mundo real. Esta caracteristica esta relacionada con la manteni- 
bilidad del codigo. 

Tratamiento de numeros reales. debido a la precision necesaria 
en ambitos de aplicacion tradicionales de los sistemas de tiempo 
real, como por ejemplo los sistemas de control. 

Fiabilidad y seguridad, en terminos de robustez del software 
desarrollado y en la utilizacion de mecanismos o esquemas que la 
garanticen. El concepto de certificacion cobra especial relevancia 
en el ambito de la fiabilidad como solucion estandar que permite 
garantizar la robustez de un determinado sistema. 

Concurrencia, debido a la necesidad real de tratar con eventos 
que ocurren de manera paralela en el mundo real. En este con- 
texto, existen lenguajes de programacion como Ada que propor- 
cionan un soporte nativo a la concurrencia. 

Funcionalidad de tiempo real, debido a la necesidad de trabajar 
con elementos temporales a la hora de construir un sistema de 
tiempo real, asi como establecer las acciones a realizar ante el 
incumplimiento de un requisito temporal. 

Interaccion HW, ya que la propia naturaleza de un sistema em- 
potrado requiere la interaccion con dispositivos hardware. 
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■ Eficiencia. debido a que la implementacion de, por ejemplo, un 
sistema critico ha de ser mas eficiente que en otro tipo de siste- 
mas. 



En el capitulo 5 se cubriran mas aspectos de los sistemas de tiempo 
real. En concreto, se abordara el tema de la planificacion en sistemas 
de tiempo real y se discutiran distintos metodos para realizar el calculo 
del tiempo de respuesta. Este calculo es esencial para determinar si un 
sistema de tiempo real es planificable, es decir, si las distintas tareas 
que lo componen son capaces de garantizar una respuesta antes de 
un determinado tiempo limite o deadline. 



1.3.2. Herramientas para sistemas de tiempo real 

El abanico de herramientas existentes para el diseno y desarrollo 
de sistemas de tiempo real es muy amplio, desde herramientas de mo- 
delado, sistemas operativos y lenguajes de programacion hasta estan- 
dares de diversa naturaleza pasando por compiladores y depuradores. 

En el ambito particular de los lenguajes de programacion es im- 

portante destacar las distintas alternativas existentes, ya sean de mas 
bajo o mas alto nivel. Tradicionalmente, una herramienta representa- 
tiva en el desarrollo de sistemas empotrados ha sido el lenguaje en- 
samblador, debido a su flexibilidad a la hora de interactuar con el 
hardware subyacente y a la posibilidad de llevar a cabo implementa- 
ciones eficientes. Desafortunadamente, el uso de un lenguaje ensam- 
blador es costoso y propenso a errores de programacion. 

Los lenguajes de programacion de sistemas, como por ejemplo C, 
representan una solucion de mas alto nivel que tiene como principal 
ventaja su amplia utilizacion en toda la industria del software. No obs- 
tante, es necesario el uso de un sistema operativo para dar soporte a 
los aspectos esenciales de concurrencia y tiempo real. 

Asi mismo, existen lenguajes de programacion de mas alto nivel, 
como por ejemplo Ada, que si proporcionan un enfoque nativo de con- 
currencia y tiempo real. En el caso particular de Ada, su diseno estuvo 
marcado por la necesidad de un lenguaje mas adecuado para el desa- 
rrollo de sistemas criticos. 

En el caso de los sistemas operativos, es importante destacar la 
existencia de algunos sistemas de tiempo real que tienen como princi- 
pals caracteristicas el determinismo, con el objetivo de garantizar los 
tiempos de respuesta de las tareas a las que dan soporte, la integra- 
cion de la concurrencia en el ambito del tiempo real y la posibilidad de 
acceder directamente al hardware subyacente. 

Finalmente, en la industria existen diversos estandares ideados 
para simplificar el desarrollo de sistemas de tiempo real y garantizar, 
en la medida de lo posible, su interoperabilidad. Un ejemplo represen- 
tative es POSIX y sus extensiones para tiempo real. Como se discutira 
en sucesivos capitulos, el principal objetivo de POSIX es proporcionar 
una estandarizacion en las llamadas al sistema de distintos sistemas 
operativos. 



LynuxWorks 



Un ejemplo representative de 
sistema operativo de tiempo 
real es LynuxWorks, el cual 
da soporte a una virtualiza- 
cion completa en dispositivos 
empotrados. 




que rige el comportamiento de los vehiculos que comparten un tramo 
de una calzada. Esta es la esencia de los semaforos software, con- 



formando una estructura de datos que se puede utilizar en una gran 
variedad de problemas de sincronizacion. 

Asi mismo, y debido a la necesidad de compartir datos entre proce- 
sos, en este capitulo se discute el uso de los segmentos de memoria 
compartida como mecanismo basico de comunicacion entre procesos. 

Como caso particular, en este capitulo se discuten los semaforos y 
la memoria compartida en POSIX y se estudian las primitivas necesa- 
rias para su uso y manipulacion. Posterior mente, la implementacion 
planteada a partir de este estandar se utilizara para resolver algunos 
problemas clasicos de sincronizacion entre procesos, como por ejem- 
plos los filosofos comensales o los lectores-escritores. 

Sobre estos problemas clasicos se realizaran modificaciones con el 
objetivo de profundizar sobre las soluciones planteadas y las posibles 
limitaciones existentes. Asi mismo, se hara especial hincapie en la 
posibilidad de interbloqueo de algunas de las soluciones discutidas, 
con el objetivo de que el desarrollador pueda evitarlo planteando una 
solucion mas adecuada. 

Finalmente, en este capitulo tambien se discute la aplicacion de al- 
gunos patrones de diseno [5] , generalizados a partir de caracteristicas 
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compartidas por diversos problemas de sincronizacion especificos. Es- 
tos patrones pueden resultar muy utiles a la hora de afrontar nuevos 
problemas de sincronizacion. 

2.1. Concep tos basicos 

Un semaforo es una herramienta de sincronizacion generica e in- 
dependiente del dominio del problema, ideada por Dijsktra en 1965. 
Basicamente, un semaforo es similar a una variable entera pero con 
las tres diferencias siguientes: 

1. Al crear un semaforo, este se puede inicializar con cualquier valor 
entero. Sin embargo, unavez creado, solo es posible incrementar 
y decrementar en uno su valor. De hecho, no se debe leer el valor 
actual de un semaforo. 

2. Cuando un proceso decrementa el semaforo, si el resultado es 
negativo entonces dicho proceso se bloquea a la espera de que 
otro proceso incremente el semaforo. 

3. Cuando un proceso incrementa el semaforo, si hay otros procesos 
bloqueados entonces uno de ellos se desbloqueara. 

Las operaciones de sincronizacion de los semaforos son, por lo tan- 
to, dos: wait y signal. Estas operaciones tambien se suelen denominar 
P (del holandes Proberen) y V (del holandes Verhogen). 

Todas las modificaciones del valor entero asociado a un semaforo se 
han de ejecutar de manera atomica, es decir, de forma indivisible. En 
otras palabras, cuando un proceso modifica el valor de un semaforo, 
ningun otro proceso puede modificarlo de manera simultanea. 




Los semaforos solo se deben manipular mediante las operacio- 
nes atomicas wait y signal. 



A continuacion se muestra la definicion de wait(): 



Listado 2.1: Definicion de wait 



wait (s) { 

while s <= 0; //No hacer nada . 
s — ; 

4 } 
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p : proceso 



creaci6n 

[inicializacion] 



wait 

[decremento] 



p^ proceso 




wait 
[p bloqueado] 



p : proceso 



[p desbloqueado] 




signal 

[incremento] 



p : proceso 



p : proceso 



Figura 2.2: Modelo de funcionamiento de un semaforo. El proceso pi se bloquea al 
ejecutar wait sobre el semaforo hasta que p2 emlta un signal sobre el mlsmo. 



La definicion de signalf) es la siguiente: 



Listado 2.2: Definicion de signal 



do{ 



wait (sem) 



SECCION_CRITICA 



[ signal (sem) j 



[ 



SECCION_RESTANTE 



} while (l); 

Figura 2.1: El acceso a la 
seccion critlca de un proceso 
se puede controlar median- 
te un semaforo. Note como 
el acceso a dlcho secclon se 
gestlona medinate el semafo- 
ro binarlo denomlnado sem. 



signal (s) { 

2 s++; 

3 } 



Los semaforos se suelen clasificar en semaforos contadores y se- 
maforos binarios. Un semaforo contador es aquel que permite que 
su valor pueda variar sin restricciones, mientras que en un semaforo 
binario dicho valor solo puede ser 0 6 1. Tradicionalmente, los sema- 
foros binarios se suelen denominar mutex. 

En el contexto del problema de la seccion critica discutido en la 
seccion 1.2.2, los semaforos binarios se pueden utilizar como meca- 
nismo para garantizar el acceso exclusivo a la misma, evitando asi las 
ya discutidas condiciones de carrera. En este contexto, los procesos 
involucrados compartirian un semaforo inicializado a 1 , mientras que 
su funcionamiento estaria basado en el esquema de la figura 2.1. 

Por otra parte, los semaforos contadores se pueden utilizar para 
gestionar el acceso concurrente a las distintas instancias que con- 
forman un recurso. En este caso, el semaforo se inicializaria al nu- 
mero de instancias disponibles originalmente. Asi, cuando un proceso 
Pi deseara adquirir una instancia del recurso, ejecutaria wait sobre el 
semaforo decrementando el valor del mismo. 
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Figura 2.3: Ejemplo de sincronizacion entre procesos mediante semaforos. 



Por el contrario, cuando un proceso p t liberara dicha instancia, eje- 
cutaria signal sobre el recurso incrementando el valor del mismo. Si 
el semaforo llegase a 0, entonces todas las instancias del recurso es- 
tarian ocupadas. Ante esta situacion, si otro proceso pj ejecuta wait, 
entonces se bloquearia hasta que el valor del semaforo sea mayor que 
0, es decir, hasta que otro proceso ejecutara signal. 

Los semaforos tambien se usan para sincronizar eventos, delimi- 
tando hasta que punto puede llegar un proceso ejecutando su codigo 
antes de que otro proceso alcance otro punto de su codigo. La figura 
2.3 muestra la estructura de tres procesos (PI, P2 y P3) en base a sus 
instrucciones y los puntos de sincronizacion entre dichos procesos. 

Un punto de sincronizacion, representado mediante lineas azules 
en la figura, especifica si una instruccion de un proceso se ha de eje- 
cutar, obligate riamente, antes que otra instruccion especifica de otro 
proceso. Para cada punto de sincronizacion se ha definido un semaforo 
binario distinto, inicializado a 0. Por ejemplo, el punto de sincroniza- 
cion asociado al semaforo a implica que la operacion si, del proceso 
P2, se ha de ejecutar antes que la operacion r3 para que el proceso PI 
pueda continuar su ejecucion. 

Ademas de estos aspectos basicos que conforman la definicion de 
un semaforo, es importante considerar las siguientes consecuencias 
derivadas de dicha definicion: 



Sincronizacion 

La sincronizacion tambien se 
refiere a situaciones en las 
que se desea evitar que dos 
eventos ocurran al mismo 
tiempo o a forzar que uno 
ocurra antes o despues que 
otro. 



■ En general, no es posible conocer si un proceso se bloqueara 
despues de decrementar el semaforo. 



2.2. Implementacion 
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■ No es posible conocer que proceso se despertara, en caso de que 
haya alguno bloqueado, despues de que se incremente el sema- 
foro. 

■ Cuando se incrementa el semaforo, el numero de procesos que se 
desbloquearan sera uno o cero. Es decir, no se ha de despertar 
algun proceso necesariamente. 

El uso de los semaforos como mecanismo de sincronizacion plantea 
una serie de ventajas, derivadas en parte de su simplicidad: 

■ Los semaforos permiten imponer restricciones explicitas con el 
objetivo de evitar errores por parte del programador. 

■ Las soluciones basadas en semaforos son, generalmente, limpias 
y organizadas, garantizando su simplicidad y permitiendo demos- 
trar su validez. 

■ Los semaforos se pueden implementar de forma eficiente en una 
gran variedad de sistemas, fomentando asi la portabilidad de las 
soluciones planteadas. 

Antes de discutir los semaforos en POSIX, es importante destacar 
que la definicion de semaforo discutida en esta seccion requiere una 
espera activa. Mientras un proceso este en su seccion critica, cual- 
quier otro proceso que intente acceder a la suya debera ejecutar de 
manera continuada un bucle en el codigo de entrada. Este esquema 
basado en espera activa hace que se desperdicien miles de ciclos de 
CPU en un sistema multiprogramado, aunque tiene la ventaja de que 
no se producen cambios de contexto. 

Para evitar este tipo de problematica, es posible habilitar el bloqueo 
de un proceso que ejecuta wait sobre un semaforo con valor negative 
Esta operacion de bloqueo coloca al proceso en una cola de espera 
vinculada con el semaforo de manera que el estado del proceso pasa 
a en espera. Posterior mente, el control pasa al planificador de la CPU, 
que seleccionara otro proceso para su ejecucion. 

Un proceso bloqueado se reanudara cuando otro proceso ejecuta 
signal sobre el semaforo, cambiando el estado del proceso original de 
en espera a preparado. 



2.2. Implementacion 

2.2.1. Semaforos 

En esta seccion se discuten las primitivas POSIX mas importantes 
relativas a la creacion y manipulacion de semaforos y segmentos de 
memoria compartida. Asi mismo, se plantea el uso de una interfaz que 
facilite la manipulacion de los semaforos mediantes funciones basicas 
para la creacion, destruccion e interaccion mediante operaciones wait 
y signal 



[48] 



CAPITULO 2. SEMAFOROS Y MEMORIA COMPARTIDA 



En POSIX, existe la posibilidad de manejar semaforos nombrados, 

es decir, semaforos que se pueden manipular mediante cadenas de 
texto, facilitando asi su manejo e incrementando el nivel semantico 
asociado a los mismos. 

En el siguiente listado de codigo se muestra la interfaz de la primi- 
tiva sem_open(), utilizada para abrir un semaforo nombrado. 



Listado 2.3: Primitiva sem open en POSIX. 



#include <semaphore . h> 

2 

3 /* Devuelve un puntero al semaforo o SEM FAILED */ 
sem_t *sem_open ( 

const char *name, /* Nombre del semaforo */ 
int oflag, /* Flags */ 

mode_t mode, /* Permisos */ 

unsigned int value /* Valor inicial */ 

9 ) ; 
10 

sem_t *sem_open ( 

const char *name, /* Nombre del semaforo */ 
int oflag, /* Flags */ 

14 ) ; 



El valor de retorno de la primitiva sem_open() es un puntero a una 
estructura del tipo sem_t que se utilizara para llamar a otras funciones 
vinculadas al concepto de semaforo. 

POSIX contempla diversas primitivas para cerrar [sem_close()) y eli- 
minar (sem_u.nlinkO) un semaforo, liberando asi los recursos previa- 
mente creados por sem_open(). La primera tiene como parametro un 
puntero a semaforo, mientras que la segunda solo necesita el nombre 
del mismo. 



Control de errores 



Recuerde que primitivas co- 
mo sem_close y sem_unlmk 
tambien devuelven codigos 
de error en caso de fallo. 



Listado 2.4: Primitivas sem close y sem unlink en POSIX. 



#include <semaphore . h> 

2 

3 /* Devuelven 0 si todo correcto o -1 en caso de error */ 
int sem_close (sem_t *sem) ; 
int sem_unlink (const char *name) ; 



Finalmente, las primitivas para decrementar e incrementar un se- 
maforo se exponen a continuacion. Note como la primitiva de incre- 
mento utiliza el nombre post en lugar del tradicional signal. 



Listado 2.5: Primitivas sem wait y sem post en POSIX. 



#include <semaphore . h> 

2 

3 /* Devuelven 0 si todo correcto o -1 en caso de error */ 
int sem_wait (sem_t *sem) ; 
int sem_post {sem_t *sem) ; 



En el presente capitulo se utilizaran los semaforos POSIX para co- 
dificar soluciones a diversos problemas de sincronizacion que se iran 
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planteando en la seccion 2.3. Para facilitar este proceso se ha definido 
una interfaz con el objetivo de simplificar la manipulacion de dichos 
semaforos, el cual se muestra en el siguiente listado de codigo. 



Listado 2.6: Interfaz de gestion de semaforos. 



#include <semaphore . h> 

2 

typedef int bool; 
fdefine false 0 
fdefine true 1 

6 

7 / * Crea un semaforo POSIX */ 

sem_t *crear_sem (const char *name, unsigned int valor) ; 

9 

10 /* Obtener un semaforo POSIX (ya existente) */ 

11 sem_t *get_sem (const char *name) ; 
12 

13 /* Cierra un semaforo POSIX */ 

void destruir_sem (const char *name) ; 

15 

16 /* Incrementa el semaforo */ 
void signal_sem (sem_t *sem) ; 

18 

19 /* Decrementa el semaforo */ 

20 void wait_sem (sem_t *sem) ; 



Patron fachada 



La interfaz de gestion de se- 
maforos propuesta en esta 
seccion es una implementa- 
cion del patron fachada faca- 
de. 



El diseno de esta interfaz se basa en utilizar un esquema similar 
a los semaforos nombrados en POSIX, es decir, identificar a los se- 
maforos por una cadena de caracteres. Dicha cadena se utilizara para 
crear un semaforo, obtener el puntero a la estructura de tipo sem_t 
y destruirlo. Sin embargo, las operaciones wait y signal se realizaran 
sobre el propio puntero a semaforo. 



2.2.2. Memoria compartida 

Los problemas de sincronizacion entre procesos suelen integrar al- 
gun tipo de recurso compartido cuyo acceso, precisamente, hace ne- 
cesario el uso de algun mecanismo de sincronizacion como los sema- 
foros. El recurso compartido puede ser un fragmento de memoria, 
por lo que resulta relevante estudiar los mecanismos proporcionados 
por el sistema operativo para dar soporte a la memoria compartida. 
En esta seccion se discute el soporte POSIX para memoria comparti- 
da, haciendo especial hincapie en las primitivas proporcionadas y en 
un ejemplo particular. 

La gestion de memoria compartida en POSIX implica la apertura 
o creacion de un segmento de memoria compartida asociada a un 
nombre particular, mediante la primitiva shm_open(). En POSIX, los 
segmentos de memoria compartida actuan como archivos en memoria. 
Una vez abiertos, es necesario establecer el tamano de los mismos me- 
diante f truncated para, posteriormente, mapear el segmento al espacio 
de direcciones de memoria del usuario mediante la primitiva mmap. 
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A continuacion se expondran las primitivas POSIX necesarias pa- 
ra la gestion de segmentos de memoria compartida. Mas adelante, se 
planteara un ejemplo concreto para compartir una variable entera. 



Listado 2.7: Primitivas shm open y shm unlink en POSIX. 



#include <mman.h> 

2 

3 /* Devuelve el descriptor de archivo o -1 si error */ 
int shm_open ( 

const char *name, /* Nombre del segmento */ 
int of lag, /* Flags */ 

mode_t mode /* Permisos */ 

) ; 

9 

10 /* Devuelve 0 si todo correcto o -1 en caso de error */ 

11 int shm_unlink ( 

const char *name /* Nombre del segmento */ 

13 ) ; 



Recuerde que, cuando haya terminado de usar el descriptor del 
archivo, es necesario utilizar closed como si se tratara de cualquier 
otro descriptor de archivo. 



Listado 2.8: Primitiva close. 



#include <unistd.h> 

2 

int close ( 

int fd /* Descriptor del archivo */ 

) ; 



Despues de crear un objeto de memoria compartida es necesario 
establecer de manera explicita su longitud mediante /truncated, ya 
que su longitud inicial es de cero bytes. 



Listado 2.9: Primitiva ftruncate. 



#include <unistd.h> 
#include <sys /types . h> 

3 

int ftruncate ( 

int fd, /* Descriptor de archivo */ 

off_t length /* Nueva longitud */ 

) ; 



A continuacion, se mapea el objeto al espacio de direcciones del 
usuario mediante mmapQ. El proceso inverso se realiza mediante la 
primitiva munmapQ. La funcion mmapO se utiliza para la creacion, 
consulta y modificacion de valor almacena en el objeto de memoria 
compartida. 
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Listado 2.10: Primitiva mmap. 



#include <sys/mman.h> 

2 

3 void *mmap ( 

void *addr, 
5 size_t length, 

int prot, 

int flags, 

8 int fd, 

9 off_t offset 
10 ) ; 
11 

12 int munmap ( 

13 void *addr, /* Direccion de memoria */ 

14 size_t length /* Longitud del segmento */ 

15 ) ; 



/* Direccion de memoria */ 

/* Longitud del segmento */ 

/* Proteccion */ 

/* Flags */ 

/* Descriptor de archivo */ 

/* Desplazamiento */ 



Compartiendo un valor entero 

En funcion del dominio del problema a resolver, el segmento u obje- 
to de memoria compartida tendra mas o menos longitud. Por ejemplo, 
seria posible definir una estructura especifica para un tipo abstracto 
de datos y crear un segmento de memoria compartida para que distin- 
tos procesos puedan modificar dicho segmento de manera concurren- 
te. En otros problemas solo sera necesario utilizar un valor entero a 
compartir entre los procesos. La creacion de un segmento de memoria 
para este ultimo caso se estudiara a continuacion. 

Al igual que en el caso de los semaforos, se ha definido una interfaz 
para simplicar la manipulacion de un valor entero compartido. Dicha 
interfaz facilita la creacion, destruccion, modificacion y consulta de 
un valor entero que puede ser compartido por multiples procesos. Al 
igual que en el caso de los semaforos, la manipulacion del valor en- 
tero se realiza mediante un esquema basado en nombres, es decir, se 
hacen uso de cadenas de caracteres para identificar los segmentos de 
memoria compartida. 



Listado 2.11: Interfaz de gestion de un valor entero compartido. 



1 /* Crea un objeto de memoria compartida */ 

2 /* Devuelve el descriptor de archivo */ 

I int crear_var (const char *name, int valor) ; 
4 

5 /* Obtiene el descriptor asociado a la variable */ 

6 int obtener_var (const char *name); 
7 

8 /* Destruye el objeto de memoria compartida */ 
void destruir_var (const char *name) ; 

10 

11 /* Modifica el valor del objeto de memoria compartida */ 

12 void modif icar_var (int shm_fd, int valor) ; 
13 

14 /* Devuelve el valor del objeto de memoria compartida */ 

15 void consultar_var (int shm_fd, int *valor) ; 
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Resulta interesante resaltar que la funcion consultar almacena el 
valor de la consulta en la variable valor, pasada por referenda. Este 
esquema es mas eficiente, evita la generacion de copias en la propia 
funcion y facilita el proceso de unmapping. 

En el siguiente listado de codigo se muestra la implementacion de 
la funcion crear_var cuyo objetivo es el de crear e inicializar un seg- 
mento de memoria compartida para un valor entero. Note como es 
necesario llevar a cabo el mapping del objeto de memoria compartida 
con el objetivo de asignarle un valor (en este caso un valor entero). 



Listado 2. 12: Creacion de un segmento de memoria compartida. 



int crear_var (const char *name, int valor) { 



2 int shm_fd; 

3 int *p; 
4 

5 /* Abre el objeto de memoria compartida */ 

shm_fd = shm_open (name, 0_CREAT | 0_RDWR, 0644); 
7 if (shm_fd == -1) { 

fprintf (stderr, "Error al crear la variable: %s\n", 
strerror (errno) ) ; 
10 exit (EXIT_FAILURE) ; 

} 

12 

13 /* Establecer el tamario */ 

14 if ( f truncate (shm_fd, sizeof (int) ) == -1) { 

fprintf (stderr, "Error al truncar la variable: %s\n", 

16 strerror (errno) ) ; 

17 exit (EXIT_FAILURE) ; 

} 

19 

20 /* Mapeo del objeto de memoria compartida */ 

21 p = mmap(NULL, sizeof (int), PR0T_READ | PROT_WRITE, MAP_SHARED, 

shm_fd, 0) ; 

22 if (p == MAP_FAILED) { 

fprintf (stderr, "Error al mapear la variable: %s\n", 

24 strerror (errno) ) ; 

25 exit (EXIT_FAILURE) ; 
} 

27 

*p = valor; 
29 munmap(p, sizeof (int) ) ; 

30 

31 return shm_fd; 



32 } 



Posteriormente, es necesario establecer el tamano de la variable 
compartida, mediante la funcion/truncate, asignar de manera explicita 
el valor y, fmalmente, realizar el proceso de unmapping mediante la 
funcion munmap. 



2.3. Problemas clasicos de sincronizacion 
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2.3. Problemas clasicos de sincronizacion 

En esta seccion se plantean algunos problemas clasicos de sincro- 
nizacion y se discuten posibles soluciones basadas en el uso de sema- 
foros. En la mayor parte de ellos tambien se hace uso de segmentos 
de memoria compartida para compartir datos. 



2.3.1. El buffer limitado 

El problema del buffer limitado ya se presento en la seccion 1.2.1 
y tambien se suele denominar el problema del productor/ consumidor. 
Basicamente, existe un espacio de almacenamiento comun limitado, 
es decir, dicho espacio consta de un conjunto finito de huecos que 
pueden contener o no elementos. Por una parte, los productores in- 
sertaran elementos en el buffer. Por otra parte, los consumidores los 
extraeran. 

La primera cuestion a considerar es que se ha de controlar el acce- 
so exclusivo a la seccion critica, es decir, al propio buffer. La segunda 
cuestion importante reside en controlar dos situaciones: i) no se pue- 
de insertar un elemento cuando el buffer esta lleno y ii) no se puede 
extraer un elemento cuando el buffer esta vacio. En estos dos casos, 
sera necesario establecer un mecanismo para bloquear a los procesos 
correspondientes . 



Secci6n critica 



Productor 



Consumidor 



Figura 2.4: Esquema grafico del problema del buffer limitado. 



Para controlar el acceso exclusivo a la seccion critica se puede uti- 
lizar un semaforo binario, de manera que la primitiva wait posibilite 
dicho acceso o bloquee a un proceso que desee acceder a la seccion cri- 
tica. Para controlar las dos situaciones anteriormente mencionadas, se 
pueden usar dos semaforos independientes que se actualizaran cuan- 
do se produzca o se consuma un elemento del buffer, respectivamente. 

La solucion planteada se basa en los siguientes elementos: 

■ mutex, semaforo binario que se utiliza para proporcionar exclu- 
sion mutua para el acceso al buffer de productos. Este semaforo 
se inicializa a 1. 

■ empty, semaforo contador que se utiliza para controlar el nume- 
ro de huecos vacios del buffer. Este semaforo se inicializa a n, 
siendo n el tamano del buffer. 
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/ 

while (1) { 

// Produce en nextP. 
wait (empty) ; 
wait (mutex) ; 

// Guarda nextP en buffer, 
signal (mutex) ; 
signal (full) ; 

} 

V 



Figura 2.5: Procesos productor y consumidor sincronizados mediante un semaforo. 

■ full, semaforo contador que se utiliza para controlar el numero 
de huecos llenos del buffer. Este semaforo se inicializa a 0. 

En esencia, los semaforos empty y full garantizan que no se pue- 
dan insertar mas elementos cuando el buffer este lleno o extraer mas 
elementos cuando este vacio, respectivamente. Por ejemplo, si el valor 
interno de empty es 0, entonces un proceso que ejecute wait sobre 
este semaforo se quedara bloqueado hasta que otro proceso ejecute 
signal, es decir, hasta que otro proceso produzca un nuevo elemento 
en el buffer. 

La figura 2.5 muestra una posible solucion, en pseudocodigo, del 
problema del buffer limitado. Note como el proceso productor ha de 
esperar a que haya algun hueco libre antes de producir un nuevo 
elemento, mediante la operacion wait(empty)). El acceso al buffer se 
controla mediante wait(mutex), mientras que la liberacion se realiza 
con signal(mutex). Finalmente, el productor indica que hay un nuevo 
elemento mediante signal(empty). 

Patrones de sincronizacion 

En la solucion planteada para el problema del buffer limitado se 
pueden extraer dos patrones basicos de sincronizacion con el objetivo 
de reusarlos en problemas similares. 

Uno de los patrones utilizados es el patron mutex [5], que basi- 
camente permite controlar el acceso concurrente a una variable com- 
partida para que este sea exclusivo. En este caso, dicha variable com- 
partida es el buffer de elementos. El mutex se puede entender como 
la Have que pasa de un proceso a otro para que este ultimo pueda 
proceder. En otras palabras, un proceso (o hilo) ha de tener acceso al 
mutex para poder acceder a la variable compartida. Cuando termine 
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de trabajar con la variable compartida, entonces el proceso liberara el 
mutex. 

El patron mutex se puede implementar de manera sencilla median- 
te un semaforo binario. Cuando un proceso intente adquirir el mutex, 
entonces ejecutara wait sobre el mismo. Por el contrario, debera eje- 
cutar signal para liberarlo. 



Proceso A 



wait (mutex) ; 

// Seccion critica 

cont = cont + 1; 
signal (mutex) ; 



Proceso B 



wait (mutex) ; 

/ / Seccion critica 

cont = cont - 1; 
signal (mutex) ; 



Figura 2.6: Aplicacion del patron mutex para acceder a la variable compartida cont. 



Por otra parte, en la solucion del problema anterior tambien se ve 
reflejado un patron de sincronizacion que esta muy relacionado con 
uno de los principales usos de los semaforos: el patron senalizacion 
[5]. Basicamente, este patron se utiliza para que un proceso o hilo 
pueda notificar a otro que un determinado evento ha ocurrido. En 
otras palabras, el patron senalizacion garantiza que una seccion de 
codigo de un proceso se ejecute antes que otra seccion de codigo de 
otro proceso, es decir, resuelve el problema de la serializacion. 

En el problema del buffer limitado, este patron lo utiliza el consumi- 
dor para notificar que existe un nuevo item en el buffer, posibilitando 
asi que el productor pueda obtenerlo, mediante el wait correspondien- 
te sobre el semaforo empty. 



Proceso A 



sentencia al 
signal (sem) ; 



Proceso B 



wait ( sem) ; 
sentencia bl; 



Figura 2.7: Patron senalizacion para la serializacion de eventos. 



2.3.2. Lectores y escritores 

Suponga una estructura o una base de datos compartida por va- 
rios procesos concurrentes. Algunos de estos procesos simplemente 
tendran que leer informacion, mientras que otros tendran que actuali- 
zarla, es decir, realizar operaciones de lectura y escritura. Los primeros 
procesos se denominan lectores mientras que el resto seran escritores. 



[56] 



CAPITULO 2. SEMAFOROS Y MEMORIA COMPARTIDA 



Si dos o mas lectores intentan acceder de manera concurrente a 
los datos, entonces no se generara ningun problema. Sin embargo, 
un acceso simultaneo de un escritor y cualquier otro proceso, ya sea 
lector o escritor, generaria una condicion de carrera. 

El problema de los lectores y escritores se ha utilizado en innume- 
rables ocasiones para probar distintas primitivas de sincronizacion y 
existen multitud de variaciones sobre el problema original. La version 
mas simple se basa en que ningun lector tendra que esperar a menos 
que ya haya un escritor en la seccion critica. Es decir, ningun lector ha 
de esperar a que otros lectores terminen porque un proceso escritor 
este esperando. 

En otras palabras, un escritor no puede acceder a la seccion critica 
si alguien, ya sea lector o escritor, se encuentra en dicha seccion. Por 
otra parte, mientras un escritor se encuentra en la seccion critica, 
ninguna otra entidad puede acceder a la misma. Desde otro punto 
de vista, mientras haya lectores, los escritores esperaran y, mientras 
haya un escritor, los lectores no leeran. 

El numero de lectores representa una variable compartida, cuyo 
acceso se debera controlar mediante un semaforo binario aplicando, 
de nuevo, el patron mutex. Por otra parte, es necesario modelar la sin- 
cronizacion existente entre los lectores y los escritores, es decir, habra 
que considerar el tipo de proceso que quiere acceder a la seccion cri- 
tica, junto con el estado actual, para determinar si un proceso puede 
acceder o no a la misma. Para ello, se puede utilizar un semaforo bi- 
nario que gobierne el acceso a la seccion critica en funcion del tipo de 
proceso (escritor o lector), considerando la prioridad de los lectores 
frente a los escritores. 

La solucion planteada, cuyo pseudocodigo se muestra en la figura 
2.8, hace uso de los siguientes elementos: 

■ numjectores. una variable compartida, inicializada a 0, que sir- 
ve para contar el numero de lectores que acceden a la seccion 
critica. 

■ mutex, un semaforo binario, inicializado a 1, que controla el ac- 
ceso concurrente a num_lectores. 

■ acceso_esc, un semaforo binario, inicializado a 1, que sirve para 
dar paso a los escritores. 

En esta primera version del problema se prioriza el acceso de los 
lectores con respecto a los escritores, es decir, si un lector entra en 
la seccion critica, entonces se dara prioridad a otros lectores que es- 
ten esperando frente a un escritor. La implementacion garantiza esta 
prioridad debido a la ultima sentencia condicional del codigo del pro- 
ceso lector, ya que solo ejecutara signal sobre el semaforo acceso_esc 
cuando no haya lectores. 
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Proceso lector 



Proceso escritor 



wait (mutex) ; 

num_lectores++ ; 

if num lectores == 1 



then 



wait (acceso_esc) ; 
/* SC: Escritura */ 

/ * * / 

signal (acceso_esc) ; 



wait (acceso esc) ; 



signal (mutex) ; 

/* SC: Lectura */ 

/* ... */ 



wait (mutex) ; 

num_lectores — ; 

if num lectores == 0 



then 



signal (acceso_esc) 



signal (mutex) ; 



Figura 2.8: Pseudocodigo de los procesos lector y escritor. 



Cuando un proceso se queda esperando una gran cantidad de 
tiempo porque otros procesos tienen prioridad en el uso de los 
recursos, este se encuentra en una situacion de inaniclon o 
starvation. 



La solucion planteada garantiza que no existe posibilidad de in- 
terbloqueo pero se da una situacion igualmente peligrosa, ya que un 
escritor se puede quedar esperando indefinidamente en un estado de 
inanicion (starvation) si no dejan de pasar lectores. 

Priorizando escritores 

En esta seccion se plantea una modificacion sobre la solucion an- 
terior con el objetivo de que, cuando un escritor llegue, los lectores 
puedan finalizar pero no sea posible que otro lector tenga prioridad 
sobre el escritor. 

Para modelar esta variacion sobre el problema original, sera nece- 
sario contemplar de algun modo esta nueva prioridad de un escritor 
sobre los lectores que esten esperando para acceder a la seccion criti- 
ca. En otras palabras, sera necesario integrar algun tipo de mecanismo 
que priorice el turno de un escritor frente a un lector cuando ambos 
se encuentren en la seccion de entrada. 

Una posible solucion consiste en anadir un semaforo turno que go- 
bierne el acceso de los lectores de manera que los escritores puedan 
adquirirlo de manera previa. En la imagen 2.9 se muestra el pseudoco- 
digo de los procesos lector y escritor, modificados a partir de la version 
original. 
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Proceso lector 



Proceso escritor 



wait (turno) ; 
signal (turno) ; 
wait (mutex) ; 



wait (turno) ; 



wait (acceso_esc) ; 
// SC: Escritura 
// . . . 



num lectores++; 



if num lectores == 1 



then 



signal (turno) ; 



wait (acceso esc) ; 



signal (acceso_esc) ; 



signal (mutex) ; 
// SC: Lectura 
// . . . 

wait (mutex) ; 

num_lectores--; 

if num_lectores == 0 then 
signal (acceso_esc) ; 
signal (mutex) ; 



Figura 2.9: Pseudocodigo de los lectores y escritores sin starvation. 

Si un escritor se queda bloqueado al ejecutar wait sobre dicho se- 
maforo, entonces forzara a futures lectores a esperar. Cuando el ul- 
timo lector abandona la seccion critica, se garantiza que el siguiente 
proceso que entre sera un escritor. 

Como se puede apreciar en el proceso escritor, si un escritor llega 
mientras hay lectores en la seccion critica, el primero se bloqueara en 
la segunda sentencia. Esto implica que el semaforo turno este cerra- 
do, generando una barrera que encola al resto de lectores mientras el 
escritor sigue esperando. 

Respecto al lector, cuando el ultimo abandona y efectua signal so- 
bre acceso_esc, entonces el escritor que permanecia esperando se des- 
bloquea. A continuacion, el escritor entrara en su seccion critica de- 
bido a que ninguno de los otros lectores podra avanzar debido a que 
turno los bloqueara. 

Cuando el escritor termine realizando signal sobre turno, entonces 
otro lector u otro escritor podra seguir avanzando. Asi, esta solucion 
garantiza que al menos un escritor continue su ejecucion, pero es po- 
sible que un lector entre mientras haya otros escritores esperando. 

En funcion de la aplicacion, puede resultar interesante dar prio- 
ridad a los escritores, por ejemplo si es critico tener los datos conti- 
nuamente actualizados. Sin embargo, en general, sera el planificador, 
y no el programador el responsable de decidir que proceso o hilo en 
concreto se desbloqueara. 
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t,C6mo modificaria la solucion propuesta para garantizar que, 
cuando un escritor llegue, ningun lector pueda entrar en su 
seccion critlca hasta que todos los escritores hayan termlnado? 



Patrones de sincronizacion 

El problema de los lectores y escritores se caracteriza porque la pre- 
sencia de un proceso en la seccion critica no excluye necesariamente 
a otros procesos. Por ejemplo, la existencia de un proceso lector en la 
seccion critica posibilita que otro proceso lector acceda a la misma. No 
obstante, note como el acceso a la variable compartida num_lectores 
se realiza de manera exclusiva mediante un mutex. 

Sin embargo, la presencia de una categoria, por ejemplo la categoria 
escritor, en la seccion critica si que excluye el acceso de procesos de 
otro tipo de categoria, como ocurre con los lectores. Este patron de 
exclusion se suele denominar exclusion mutua categorica [5]. 

Por otra parte, en este problema tambien se da una situacion que 
se puede reproducir con facilidad en otros problemas de sincroniza- 
cion. Basicamente, esta situacion consiste en que el primer proceso 
en acceder a una seccion de codigo adquiera el semaforo, mientras 
que el ultimo lo libera. Note como esta situacion ocurre en el proceso 
lector. 

El nombre del patron asociado a este tipo de situaciones es light- 
switch o interruptor [5] , debido a su similitud con un interrupter de 
luz (la primera persona lo activa o enciende mientras que la ultima lo 
desactiva o apaga). 



Listado 2.13: Implementation del patron interruptor. 



import threading 
2 from threading import Semaphore 



3 






4 


class Interruptor: 


5 
6 


def 


init (self) : 


7 




self ._contador = 0 


8 




self -_mutex = Semaphore (1) 


9 






10 


def 


activar (self, semaforo) : 


11 




self ._mutex . acquire ( ) 


12 




self ._contador += 1 


13 




if self ,_contador == 1: 


14 




semaforo . acquire ( ) 


15 




self ._mutex . release ( ) 


16 






17 


def 


desactivar (self, semaforo) 


18 




self ._mutex . acquire ( ) 


19 




self ._contador -= 1 


20 




if self ._contador == 0: 


21 




semaforo . release ( ) 


22 




self ._mutex . release ( ) 
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En el caso de utilizar un enfoque orientado a objetos, este patron 
se puede encapsular facilmente mediante una clase, como se muestra 
en el siguiente listado de codigo. 

Finalmente, el uso del semaforo turno esta asociado a patron ba- 
rrera [5] debido a que la adquisicion de turno por parte de un escritor 
crea una barrera para el resto de lectores, bloqueando el acceso a la 
seccion critica hasta que el escritor llbere el semaforo mediante signal, 
es decir, hasta que levante la barrera. 



2.3.3. Los filosofos comensales 

Los filosofos se encuentran comiendo o pensando. Todos ellos com- 
parten una mesa redonda con cinco sillas, una para cada filosofo. En 
el centra de la mesa hay una fuente de arroz y en la mesa solo hay cin- 
co palillos, de manera que cada filosofo tiene un palillo a su izquierda 
y otro a su derecha. 

Cuando un filosofo piensa, entonces se abstrae del mundo y no se 
relaciona con otros filosofos. Cuando tiene hambre, entonces intenta 
acceder a los palillos que tiene a su izquierda y a su derecha (necesita 
ambos). Naturalmente, un filosofo no puede quitarle un palillo a otro 
filosofo y solo puede comer cuando ha cogido los dos palillos. Cuando 
un filosofo termina de comer, deja los palillos y se pone a pensar. 

Este problema es uno de los problemas clasicos de sincroniza- 

cion entre procesos, donde es necesario gestionar el acceso concu- 
rrente a los recursos compartidos, es decir, a los propios palillos. En 
este contexto, un palillo se puede entender como un recurso indivisi- 
ble, es decir, en todo momento se encontrara en un estado de uso o en 
un estado de no uso. 

La solucion planteada a continuacion se basa en representar cada 
palillo con un semaforo inicializado a 1. De este modo, un filosofo 
que intente hacerse con un palillo tendra que ejecutar wait sobre el 
mismo, mientras que ejecutara signal para liberarlo (ver figura 2.11). 
Recuerde que un filosofo solo puede acceder a los palillos adyacentes 
al mismo. 

Aunque la solucion planteada garantiza que dos filosofos que esten 
sentados uno al lado del otro nunca coman juntos, es posible que el 
sistema alcance una situacion de interbloqueo. Por ejemplo, supon- 
ga que todos los filosofos cogen el palillo situado a su izquierda. En 
ese momento, todos los semaforos asociados estaran a 0, por lo que 
ningun filosofo podra coger el palillo situado a su derecha. 




Figura 2. 10: Representation 
grafica del problema de los 
filosofos comensales. En es- 
te caso concreto, clnco filoso- 
fos comparten cinco palillos. 
Para poder comer, un filosofo 
necesita obtener dos palillos: 
el de su izquierda y el de su 
derecha. 



Evitando el interbloqueo 

Una de las modificaciones mas directas para evitar un interbloqueo 
en la version clasica del problema de los filosofos comensales es limi- 
tar el numero de filosofos a cuatro. De este modo, si solo hay cuatro 
filosofos, entonces en el peor caso todos cogeran un palillo pero siem- 
pre quedara un palillo fibre. En otras palabras, si dos filosofos vecinos 
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Proceso filosofo 



while (1) { 
// Pensar . . . 
wait (palillos [i] ) ; 
wait (palillos [ (i + 1) % 5] ) ; 
// Comer . . . 
signal (palillos [i] ) ; 
signal (palillos [ (i+1) % 5] ) ; 

} 



Figura 2.11: Pseudocodigo de la solucion del problema de los filosofos comensales con 
riesgo de Interbloqueo. 



ya tienen un palillo, entonces al menos uno de ellos podra utilizar el 
palillo disponible para empezar a comer. 

El numero de filosofos de la mesa se puede controlar con un sema- 
foro contador, inicializado a dicho numero. A continuacion se muestra 
el pseudocodigo de una posible solucion a esta variante del proble- 
ma de los filosofos comensales. Como se puede apreciar, el semaforo 
sirviente gobierna el acceso a los palillos. 

Proceso filosofo 

Figura 2.12: Problema de los while (1) { 

filosofos con cuatro comen- /* Pensar... */ 

sales en la mesa. wait (sirviente) ; 

wait (palillos [i] ) ; 

wait (palillos [ (i+1) ] ) ; 

/ * Comer ... * / 

signal (palillos [i] ) ; 

signal (palillos [ (i+1) ] ) ; 

signal (sirviente) ; 

} 



'0\CJ_ 



Figura 2.13: Pseudocodigo de la solucion del problema de los filosofos comensales sin 
riesgo de interbloqueo. 



Ademas de evitar el deadlock, esta solucion garantiza que ningun 
filosofo se muera de hambre. Para ello, imagine la situacion en la que 
los dos vecinos de un filosofo estan comiendo, de manera que este ulti- 
mo esta bloqueado por ambos. Eventualmente, uno de los dos vecinos 
dejara su palillo. Debido a que el filosofo que se encontraba bloqueado 
era el unico que estaba esperando a que el palillo estuviera libre, en- 
tonces lo cogera. Del mismo modo, el otro palillo quedara disponible 
en algun instante. 
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Proceso filosofo i 

#define N 5 

#define IZQ (i-1) % 5 

#define DER (i+1) % 5 

int estado [N] ; 
sem_t mutex; 
sem_t sem [N] ; 

void filosofo (int i) { 
while (1) { 
pensar ( ) ; 

coger_palillos (i) ; 
comer ( ) ; 

de j ar_palillos (i) ; 



} 



void coger_palillos (int i) 



wait (mutex) ; 
estado [ i ] = 
prueba ( i ) ; 
signal (mutex) 
wait (sem [ i ] ) ; 



HAMBRIENTO; 



} 



void de jar_palillos (int 
wait (mutex) ; 

estado [i] = PENSANDO; 
prueba ( i - 1 ) ; 
prueba ( i + 1 ) ; 
signal (mutex) 

} 



i) ( 



void prueba (int i) { 

if (estado [i] == HAMBRIENTO &&) 
estado [izq] != COMIENDO && 
estado [der] != COMIENDO) { 
estado [i] = COMIENDO; 
signal (sem [ i] ) ; 

} 



} 



Figura 2. 14: Pseudocodigo de la solucion del problema de los filosofos comensales sin 
Interbloqueo. 



Otra posible modificacion, propuesta en el libro de A.S. Tanenbaum 
Sistemas Operativos Modernos [15], para evitar la posibilidad de inter- 
bloqueo consiste en permitir que un filosofo coja sus palillos si y solo 
si ambos palillos estan disponibles. Para ello, un filosofo debera ob- 
tener los palillos dentro de una seccion critica. En la figura 2.14 se 
muestra el pseudocodigo de esta posible modificacion, la cual incor- 
pora un array de enteros, denominado estado compartido entre los 
filosofos, que refleja el estado de cada uno de ellos. El acceso a dicho 
array ha de protegerse mediante un semaforo binario, denominado 
mutex. 

La principal diferencia con respecto al planteamiento anterior es 
que el array de semaforos actual sirve para gestionar el estado de los 
filosofos, en lugar de gestionar los palillos. Note como la funcion co- 
ger_palillos(j comprueba si el filosofo i puede coger sus dos palillos 
adyacentes mediante la funcion pruebaQ. 

La funcion dejar_palillosQ esta planteada para que el filosofo i com- 
pruebe si los filosofos adyacentes estan hambrientos y no se encuen- 
tran comiendo. 

Note que tanto para acceder al estado de un filosofo como para in- 
vocar a pruebaQ, un proceso ha de adquirir el mutex. De este modo, la 
operacion de comprobar y actualizar el array se transforma en atomi- 
ca. Igualmente, no es posible entrar en una situacion de interbloqueo 
debido a que el unico semaforo accedido por mas de un filosofo es 
mutex y ningun filosofo ejecuta wait con el semaforo adquirido. 



Compartiendo el arroz 



Una posible variacion del problema original de los filosofos comen- 
sales consiste en suponer que los filosofos comeran directamente de 
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una bandeja situada en el centro de la mesa. Para ello, los filosofos 
disponen de cuatro palillos que estan dispuestos al lado de la bande- 
ja. Asi, cuando un filosofo quiere comer, entonces tendra que coger un 
par de palillos, comer y, posteriormente, dejarlos de nuevo para que 
otro filosofo pueda comerlos. La figura 2.15 muestra de manera grafica 
la problematica planteada. 

Esta variacion admite varias soluciones. Por ejemplo, se podria uti- 
lizar un esquema similar al discutido en la solucion anterior en la que 
se evitaba el interbloqueo. Es decir, se podria pensar una solucion en 
la que se comprobara, de manera explicita, si un filosofo puede coger 
dos palillos, en lugar de coger uno y luego otro, antes de comer. 

Sin embargo, es posible plantear una solucion mas simple y ele- 
gante ante esta variacion. Para ello, se puede utilizar un semaforo 
contador inicializado a 2, el cual representa los pares de palillos dis- 
ponibles para los filosofos. Este semaforo palillos gestiona el acceso 
concurrente de los filosofos a la bandeja de arroz. 




Proceso filosofo 

while (1) { 
/ / Pensar . . . 
wait (palillos) ; 
/ / Comer . . . 
signal (palillos) ; 



Figura 2. 15: Variacion con una bandeja al centro del problema de los filosofos comensa- 
les. A la izquierda se muestra una representacion grafica, mientras que a la derecha se 
muestra una posible solucion en pseudocodigo haciendo uso de un semaforo contador. 



Patrones de sincronizacion 

La primera solucion sin interbloqueo del problema de los filosofos 
comensales y la solucion a la variacion con los palillos en el centro 
comparten una caracteristica. En ambas soluciones se ha utilizado 
un semaforo contador que posibilita el acceso concurrente de varios 
procesos a la seccion critica. 

En el primer caso, el semaforo sirviente se inicializaba a 4 para per- 
mitir el acceso concurrente de los filosofos a la seccion critica, aunque 
luego compitieran por la obtencion de los palillos a nivel individual. 

En el segundo caso, el semaforo palillos se inicializaba a 2 para 
permitir el acceso concurrente de dos procesos filosofo, debido a que 
los filosofos disponian de 2 pares de palillos. 

Este tipo de soluciones se pueden encuadrar dentro de la aplicacion 
del patron multiplex [5], mediante el uso de un semaforo contador cu- 
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ya inicializacion determina el numero maximo de procesos que pueden 
acceder de manera simultanea a una seccion de codigo. En cualquier 
otro momento, el valor del semaforo representa el numero de procesos 
que pueden entrar en dicha seccion. 

Si el semaforo alcanza el valor 0, entonces el siguiente proceso que 
ejecute wait se bloqueara. Por el contrario, si todos los procesos aban- 
donan la seccion critica, entonces el valor del semaforo volvera a n. 



wait (multiplex) ; 

// Seccion critica 
signal (multiplex) ; 



Figura 2. 16: Patron multiplex para el acceso concurrente de multiples procesos. 



2.3.4. El puente de un solo carril 

Suponga un puente que tiene una carretera con un unico carril 
por el que los coches pueden circular en un sentido o en otro. La 
anchura del carril hace imposible que dos coches puedan pasar de 
manera simultanea por el puente. El protocolo utilizado para atravesar 
el puente es el siguiente: 

■ Si no hay ningun coche circulando por el puente, entonces el 
primer coche en llegar cruzara el puente. 

■ Si un coche esta atravesando el puente de norte a sur, enton- 
ces los coches que esten en el extremo norte del puente tendran 
prioridad sobre los que vayan a cruzarlo desde el extremo sur. 

■ Del mismo modo, si un coche se encuentra cruzando de sur a 
norte, entonces los coches del extremo sur tendran prioridad so- 
bre los del norte. 

En este problema, el puente se puede entender como el recurso 
que comparten los coches de uno y otro extremo, el cual les permite 
continuar con su funcionamiento habitual. Sin embargo, los coches se 
han de sincronizar para acceder a dicho puente. 

Por otra parte, en la solucion se ha de contemplar la cuestion de la 
prioridad, es decir, es necesario tener en cuenta que si, por ejemplo, 
mientras un coche del norte este en el puente, entonces si vienen mas 
coches del norte podran circular por el puente. Es decir, un coche que 
adquiere el puente habilita al resto de coches del norte a la hora de 
cruzarlo, manteniendo la preferencia con respecto a los coches que, 
posiblemente, esten esperando en el sur. 

Por lo tanto, es necesario controlar, de algun modo, el numero de 
coches en circulacion desde ambos extremos. Si ese numero llega a 0, 
entonces los coches del otro extremo podran empezar a circular. 
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Figura 2.17: Esquema grafico del problema del puente de un solo carril. 



Una posible solucion manejaria los siguientes elementos: 

■ Puente, un semaforo binario que gestiona el acceso al mismo. 

■ CochesNorte, una variable entera compartida para almacenar el 
numero de coches que circulan por el puente, en un determinado 
instante del tiempo, desde el extremo norte. 

■ MutexN, un semaforo binario que permite controlar el acceso 
exclusivo a CochesNorte. 

■ CochesSur, una variable entera compartida para almacenar el 
numero de coches que circulan por el puente, en un determinado 
instante del tiempo, desde el extremo sur. 

■ MutexS, un semaforo binario que permite controlar el acceso ex- 
clusivo a CochesSur. 



En el siguiente listado se muestra el pseudocodigo de una posible 
solucion al problema del puente de un solo carril. Basicamente, si un 
coche viene del extremo norte, y es el primero, entonces intenta acce- 
der al puente (lineas (2-4) ) invocando a wait sobre el semaforo puente. 

Si el puente no estaba ocupado, entonces podra cruzarlo, decre- 
mentando el semaforo puente a 0 y bloqueando a los coches del sur. 
Cuando lo haya cruzado, decrementara el contador de coches que vie- 
nen del extremo norte. Para ello, tendra que usar el semaforo binario 
mutexN. Si la variable CochesNorte llega a 0, entonces liberara el puen- 
te mediante signal (linea (TTJ. 

Este planteamiento se aplica del mismo modo a los coches que pro- 
vienen del extremo sur, cambiando los semaforos y la variable com- 
partida. 
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Listado 2.14: Proceso CocheNorte. 



wait (mutexN) ; 
cochesNorte++; 
3 if cochesNorte == 1 then 
wait (puente) ; 
signal (mutexN) ; 

6 /* SC: Cruzar el puente */ 

7 /* ... */ 
wait (mutexN) ; 

cochesNorte — ; 

10 if cochesNorte == 0 then 

11 signal (puente) ; 
signal (mutexN) ; 



El anexo A contiene una solucion completa de este problema de 
sincronizacion. La implementacion de coche es generica, es decir, in- 
dependiente de si parte del extremo norte o del extremo sur. La in- 
formacion necesaria para su correcto funcionamiento (basicamente el 
nombre de los semaforos y las variables de memoria compartida) se 
envia desde el proceso manager (el que ejecuta la primitiva execlQ). 

2.3.5. El barbero dormilon 

El problema original de la barberia fue propuesto por Dijkstra, aun- 
que comunmente se suele conocer como el problema del barbero dor- 
milon. El enunciado de este problema clasico de sincronizacion se ex- 
pone a continuacion. 

La barberia tiene una sala de espera con n sillas y la habitacion del 
barbero tiene una unica silla en la que un cliente se sienta para que 
el barbero trabaje. Si no hay clientes, entonces el barbero se duerme. 
Si un cliente entra en la barberia y todas las sillas estan ocupadas, es 
decir, tanto la del barbero como las de la sala de espera, entonces el 
cliente se marcha. Si el barbero esta ocupado pero hay sillas disponi- 
bles, entonces el cliente se sienta en una de ellas. Si el barbero esta 
durmiendo, entonces el cliente lo despierta. 

Para abordar este problema clasico se describiran algunos pasos 
que pueden resultar utiles a la hora de enfrentarse a un problema de 
sincronizacion entre procesos. En cada uno de estos pasos se discutira 
la problematica particular del problema de la barberia. 

1. Identificacion de procesos, con el objetivo de distinguir las dis- 
tintas entidades que forman parte del problema. En el caso del 
barbero dormilon, estos procesos son el barbero y los clientes. 
Tipicamente, sera necesario otro proceso manager encargado del 
lanzamiento y gestion de los procesos especiflcos de dominio. 

2. Agrupacion en clases o trozos de codigo, con el objetivo de es- 
tructurar a nivel de codigo la solucion planteada. En el caso del 
barbero, el codigo se puede estructurar de acuerdo a la identifi- 
cacion de procesos. 

3. Identificacion de recursos compartidos, es decir, identificacion 
de aquellos elementos compartidos por los procesos. Sera nece- 
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Figura 2. 18: Secuencia de pasos para disenar una solucion ante un problema de sin- 
cronizacion. 



sario asociar herramientas de sincronizacion para garantizar el 
correcto acceso a dichos recursos. Por ejemplo, se tendra que 
usar un semaforo para controlar el acceso concurrente al nume- 
ro de sillas. 

4. Identificacion de eventos de sincronizacion, con el objetivo de 
delimitar que eventos tienen que ocurrir obligatoriamente antes 
que otros. Por ejemplo, antes de poder actuar, algun cliente ha 
de despertar al barbero. Sera necesario asociar herramientas de 
sincronizacion para controlar dicha sincronizacion. Por ejemplo, 
se podria pensar en un semaforo binario para que un cliente des- 
pierte al barbero. 

5. Implementacion. es decir, codificacion de la solucion plantea- 
da utilizando algun lenguaje de programacion. Por ejemplo, una 
alternativa es el uso de los mecanismos que el estandar POSIX 
define para la manipulacion de mecanismos de sincronizacion y 
de segmentos de memoria compartida. 

En el caso particular del problema del barbero dormilon se distin- 
guen claramente dos recursos compartidos: 

■ Las sillas, compartidas por los clientes en la sala de espera. 

■ El sillon, compartido por los clientes que compiten para ser aten- 
didos por el barbero. 

Para modelar las sillas se ha optado por utilizar un segmento de 
memoria compartida que representa una variable entera. Con dicha 
variable se puede controlar facilmente el numero de clientes que se 
encuentran en la barberia, modelando la situacion especifica en la 
que todas las sillas estan ocupadas y, por lo tanto, el cliente ha de 
marcharse. La variable denominada num_clientes se inicializa a 0. El 
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acceso a esta variable ha de ser exclusivo, por lo que una vez se utiliza 
el patron mutex. 

Otra posible opcion hubiera sido un semaforo contador inicializado 
al numero inicial de sillas libres en la sala de espera de la barbe- 
ria. Sin embargo, si utilizamos un semaforo no es posible modelar la 
restriccion que hace que un cliente abandone la barberia si no hay 
sillas libres. Con un semaforo, el cliente se quedaria bloqueado hasta 
que hubiese un nuevo hueco. Por otra parte, para modelar el recur - 
so compartido representado por el sillon del barbero se ha optado por 
un semaforo binario, denominado sillon, con el objetivo de garantizar 
que solo pueda haber un cliente sentado en el. 

Respecto a los eventos de sincronizacion, en este problema existe 
una interaccion directa entre el cliente que pasa a la sala del barbero, 
es decir, el proceso de despertar al barbero, y la notificacion del bar- 
bero al cliente cuando ya ha terminado su trabajo. El primer evento 
se ha modelado mediante un semaforo binario denominado barbero, 
ya que esta asociado al proceso de despertar al barbero por parte de 
un cliente. El segundo evento se ha modelado, igualmente, con otro 
semaforo binario denominado Jin, ya que esta asociado al proceso de 
notificar el final del trabajo a un cliente por parte del barbero. Ambos 
semaforos se inicializan a 0. 

En la figura 2.19 se muestra el pseudocodigo de una posible so- 
lucion al problema del barbero dormilon. Como se puede apreciar, la 
parte relativa al proceso barbero es trivial, ya que este permanece de 
manera pasiva a la espera de un nuevo cliente, es decir, permanece 
bloqueado mediante wait sobre el semaforo barbero. Cuando termina- 
do de cortar, el barbero notificara dicha finalizacion al cliente mediante 
signal sobre el semaforo Jin. Evidentemente, el cliente estara bloquea- 
do por wait. 

El pseudocodigo del proceso cliente es algo mas complejo, ya que 
hay que controlar si un cliente puede o no pasar a la sala de espera. 
Para ello, en primer lugar se ha de comprobar si todas las sillas estan 
ocupadas, es decir, si el valor de la variable compartida num_clientes 
a llegado al maximo, es decir, a las N sillas que conforman la sala de 
espera. En tal caso, el cliente habra de abandonar la barberia. Note 
como el acceso a num_clientes se gestiona mediante mutex. 

Si hay alguna silla disponible, entonces el cliente esperara su turno. 
En otras palabras, esperara el acceso al sillon del barbero. Esta situa- 
cion se modela ejecutando wait sobre el semaforo sillon. Si un cliente 
se sienta en el sillon, entonces deja una silla disponible. 

A continuacion, el cliente sentado en el sillon despertara al bar- 
bero y esperara a que este termine su trabajo. Finalmente, el cliente 
abandonara la barberia liberando el sillon para el siguiente cliente (si 
lo hubiera). 



2.3. Problemas clasicos de sincronizacion 



[69] 



Proceso cliente 



Proceso barbero 



1. si no sillas libres, 
1 . 1 marcharse 

2. si hay sillas libres, 

2 . 1 sentarse 

2.2 esperar sillon 

2.3 levantarse silla 

2 . 4 ocupar sillon 

2.5 despertar barbero 

2 . 6 esperar fin 

2.7 levantarse sillon 



wait (mutex) ; 

if num_clientes 
signal (mutex) ; 
return; 
num_clientes++ ; 
signal (mutex) ; 

wait (sillon) ; 
wait (mutex) ; 

num_clientes-- 
signal (mutex) ; 

signal (barbero) ; 
wait (fin) ; 

signal (sillon) ; 



N then 



1 . dormir 

2. despertar 

3 . cortar 

4. notificar fin 

5 . volver a 1 



while (1) { 

wait (barbero) ; 
cortar ( ) ; 
signal (fin) ; 

} 



Figura 2. 19: Pseudocodigo de la solucion al problema del barbero dormilon. 



Patrones de sincronizacion 



La solucion planteada para el problema del barbero dormilon mues- 
tra el uso del patron serialization para sincronizar tanto al cliente con 
el barbero como al contrario. Esta generalizacion se puede asociar al 
patron rendezvous [5], debido a que el problema de sincronizacion que 
se plantea se denomina con ese termino. Basicamente, la idea consis- 
te en sincronizar dos procesos en un determinado punto de ejecucion, 
de manera que ninguno puede avanzar hasta que los dos han llegado. 

En la figura 2.20 se muestra de manera grafica esta problematica 
en la que se desea garantizar que la sentencia al se ejecute antes 
que b2 y que bl ocurra antes que a2. Note como, sin embargo, no se 
establecen restricciones entre las sentencias al y bl, por ejemplo. 

Por otra parte, en la solucion tambien se refleja una situacion bas- 
tante comun en problemas de sincronizacion: la llegada del valor de 
una variable compartida a un determinado limite o umbral. Este tipo 
de situaciones se asocia al patron scoreboard o marcador [5]. 
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Proceso A Proceso B 




Figura 2.20: Patron rendezvous para la sincronizacion de dos procesos en un determi- 
nado punto. 



2.3.6. Los cambales comensales 

En una tribu de canibales todos comen de la misma olla, la cual 
puede albergar N raciones de comida. Cuando un canibal quiere co- 
mer, simplemente se sirve de la olla comun, a no ser que este vacia. 
En ese caso, el canibal despierta al cocinero de la tribu y espera hasta 
que este haya rellenado la olla. 

En este problema, los eventos de sincronizacion son dos: 

■ Si un canibal que quiere comer se encuentra con la olla vacia, 
entonces se lo notifica al cocinero para que este cocine. 

■ Cuando el cocinero termina de cocinar, entonces se lo notifica al 
canibal que lo desperto previamente. 

Un posible planteamiento para solucionar este problema podria gi- 
rar en torno al uso de un semaforo que controlara el mimero de ra- 
ciones disponibles en un determinado momento (de manera similar 
al problema del buffer limitado). Sin embargo, este planteamiento no 
facilita la notificacion al cocinero cuando la olla este vacia, ya que no 
es deseable acceder al valor interno de un semaforo y, en funcion del 
mismo, actuar de una forma u otra. 

Una alternativa valida consiste en utilizar el patron marcador pa- 
ra controlar el numero de raciones de la olla mediante una variable 
compartida. Si esta alcanza el valor de 0, entonces el canibal podria 
despertar al cocinero. 

La sincronizacion entre el canibal y el cocinero se realiza mediante 
rendezvous: 

1. El canibal intenta obtener una racion. 

2. Si no hay raciones en la olla, el canibal despierta al cocinero. 

3. El cocinero cocina y rellena la olla. 

4. El cocinero notifica al canibal. 

5. El canibal come. 
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La solucion planteada hace uso de los siguientes elementos: 

■ Num_Raciones. variable compartida que contiene el numero de 
raciones disponibles en la olla en un determinado instante de 
tiempo. 

■ Mutex, semaforo binario que controla el acceso a Num_Raciones. 

■ Empty, que controla cuando la olla se ha quedado vacia. 

■ Full, que controla cuando la olla esta llena. 

En el siguiente listado se muestra el pseudocodigo del proceso co- 
cinero, el cual es muy simple ya que se basa en esperar la llamada del 
canibal, cocinar y notificar de nuevo al canibal. 



Listado 2.15: Proceso Cocinero. 



. while (1) { 

2 wait_sem (empty ) ; 
cocinar ( ) ; 

4 signal_sem ( f ull ) ; 

5 } 



El pseudocodigo del proceso canibal es algo mas complejo, debido 
a que ha de consultar el numero de raciones disponibles en la olla 
antes de comer. 



Listado 2.16: Proceso Canibal. 



while ( 1 ) { 

wait (mutex) ; 

3 

if (num_raciones == 0) { 
signal (empty) ; 
wait (full) ; 
num_raciones = N; 

8 } 
9 

num_raciones — ; 

11 

12 signal (mutex) ; 
13 

14 comer ( ) ; 

15 } 



Como se puede apreciar, el proceso canibal comprueba el numero 
de raciones disponibles en la olla (linea (TJ. Si no hay, entonces des- 
pierta al cocinero (linea (T)) y espera a que este rellene la olla (linea (1J). 
Estos dos eventos de sincronizacion guian la evolucion de los procesos 
involucrados. 

Note como el proceso canibal modifica el numero de raciones asig- 
nando un valor constante. El lector podria haber optado porque fuera 
el cocinero el que modificara la variable, pero desde un punto de vista 
practico es mas eficiente que lo haga el canibal, ya que tiene adquirido 
el acceso a la variable mediante el semaforo mutex (lineas (2) y fizj) . 
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Posteriormente, el canibal decrementa el numero de raciones (linea 
(12 ]) e invierte un tiempo en comer (linea [it). 

2.3.7. El problema de Santa Claus 

Santa Claus pasa su tiempo de descanso, durmiendo, en su casa 
del Polo Norte. Para poder despertarlo, se ha de cumplir una de las 
dos condiciones siguientes: 

1. Que todos los renos de los que dispone, nueve en total, hayan 
vuelto de vacaciones. 

2. Que algunos de sus duendes necesiten su ayuda para fabricar 
un juguete. 

Para permitir que Santa Claus pueda descansar, los duendes han 
acordado despertarle si tres de ellos tienen problemas a la hora de 
fabricar un juguete. En el caso de que un grupo de tres duendes esten 
siendo ayudados por Santa, el resto de los duendes con problemas 
tendran que esperar a que Santa termine de ayudar al primer grupo. 

En caso de que haya duendes esperando y todos los renos hayan 
vuelto de vacaciones, entonces Santa Claus decidira preparar el trineo 
y repartir los regalos, ya que su entrega es mas importante que la 
fabricacion de otros juguetes que podria esperar al ano siguiente. El 
ultimo reno en llegar ha de despertar a Santa mientras el resto de 
renos esperan antes de ser enganchados al trineo. 

Para solucionar este problema, se pueden distinguir tres procesos 
basicos: i) Santa Claus, ii) duende y iii) reno. Respecto a los recursos 
compartidos, es necesario controlar el numero de duendes que, en un 
determinado momento, necesitan la ayuda de Santa y el numero de 
renos que, en un determinado momento, estan disponibles. Evidente- 
mente, el acceso concurrente a estas variables ha de estar controlado 
por un semaforo binario. 

Respecto a los eventos de sincronizacion, sera necesario disponer 
de mecanismos para despertar a Santa Claus, notificar a los renos 
que se han de enganchar al trineo y controlar la espera por parte de 
los duendes cuando otro grupo de duendes este siendo ayudado por 
Santa Claus. 

En resumen, se utilizaran las siguientes estructuras para plantear 
la solucion del problema: 

■ Duendes, variable compartida que contiene el numero de duen- 
des que necesitan la ayuda de Santa en un determinado instante 
de tiempo. 
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■ Renos, variable compartida que contiene el numero de renos que 
han vuelto de vacaciones y estan disponibles para viajar. 

■ Mutex, semaforo binario que controla el acceso a Duendes y Re- 
nos. 

■ SantaSem, semaforo binario utilizado para despertar a Santa 
Claus. 

■ RenosSem, semaforo contador utilizado para notificar a los renos 
que van a emprender el viaje en trineo. 

■ DuendesSem, semaforo contador utilizado para notificar a los 
duendes que Santa los va a ayudar. 

■ DuendesMutex, semaforo binario para controlar la espera de 
duendes cuando Santa esta ayudando a otros. 

En el siguiente listado se muestra el pseudocodigo del proceso San- 
ta Claus. Como se puede apreciar, Santa esta durmiendo a la espera 
de que lo despierten (linea fJJ) . Si lo despiertan, sera porque los duen- 
des necesitan su ayuda o porque todos los renos han vuelto de va- 
caciones. Por lo tanto, Santa tendra que comprobar cual de las dos 
condiciones se ha cumplido. 



Listado 2.17: Proceso Santa Claus. 



1 while (1) { 



2 /* Espera a ser despertado */ 
wait ( santa_sem) ; 

4 

wait (mutex) ; 

6 

7 /* Todos los renos preparados? */ 

8 if (renos == TOTAL_RENOS ) { 

prepararTrineo ( ) ; 
10 /* Notificar a los renos. . . */ 

for (i = 0; i < TOTAL_RENOS ; i++) 
12 signal (renos_sem) ; 

-i 3 } 

14 else 

if (duendes == NUM_DUENDES_GRUPO) { 

16 ayudarDuendes ( ) ; 

17 /* Notificar a los duendes... */ 
for (i = 0; i < NUM_DUENDES_GRUPO; 

19 signal (duendes_sem) ; 

20 } 
21 

22 signal (mutex) ; 

23 } 



Si todos los renos estan disponibles (linea (Tj), entonces Santa pre- 
parara el trineo y notificara a todos los renos (lineas [9-12 J . Note como 
tendra que hacer tantas notificaciones (signal) como renos haya dis- 
ponibles. Si hay suficientes duendes para que sean ayudados (lineas 
[ 15-20) ), entonces Santa los ayudara, notificando esa ayuda de manera 
explicita (signal) mediante el semaforo DuendesSem. 
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El proceso reno es bastante sencillo, ya que simplemente despierta 
a Santa cuando todos los renos esten disponibles y, a continuacion, 
esperar la notificacion de Santa. Una vez mas, el acceso a la variable 
compartida renos se controla mediante el semaforo binario mutex. 



Listado 2.18: Proceso reno. 



vacaciones ( ) ; 

2 

wait (mutex) ; 

4 

renos += 1; 
6 /* Todos los renos listos? */ 
if (renos == TOTAL_REN0S) 
signal (santa_sem) ; 

9 

10 signal (mutex) ; 
11 

12 /* Esperar la notificacion de Santa */ 

wait (renos_sem) ; 
14 engancharTrineo ( ) ; 



Finalmente, en el proceso duende se ha de controlar la formacion 
de grupos de duendes de tres componentes antes de despertar a Santa 
(linea (J)). Si se ha alcanzado el niimero minimo para poder despertar 
a Santa, entonces se le despierta mediante signal sobre el semaforo 
SantaSem (linea \T)). Si no es asi, es decir, si otro duende necesita ayu- 
da pero no se ha llegado al numero minimo de duendes para despertar 
a Santa, entonces el semaforo DuendesMutex se libera (linea \Tj). 

El duende invocara a obtenerAyuda y esperara a que Santa notifi- 
que dicha ayuda mediante DuendesSem. Note como despues de solici- 
tar ayuda, el duende queda a la espera de la notificacion de Santa. 



Listado 2.19: Proceso duende. 



wait ( duende s_mut ex) ; 
wait (mutex) ; 

3 

4 duendes += 1 ; 

5 /* Esta completo el grupo de duendes? */ 

6 if (duendes == NUM_DUENDES_GRUPO) 

signal (santa_sem) ; 
else 

signal (duendes_mutex) ; 

10 

11 signal (mutex) ; 
12 

13 wait ( duende s_s em) ; 

14 obteniendoAyuda () ; 
15 

wait (mutex) ; 

17 

18 duendes -= 1; 

19 /* Nuevo grupo de duendes? */ 
if (duendes == 0) 

21 signal (duendes_mutex) ; 
22 

23 signal (mutex) ; 




En este capitulo se discute el concepto de paso de mensajes co- 
mo mecanismo basico de sincronizacion entre procesos. Al con- 
trario de lo que ocurre con los semaforos, el paso de mensajes 
ya maneja, de manera implicita, el intercambio de informacion entre 
procesos, sin tener que recurrir a otros elementos como por ejemplo el 
uso de segmentos de memoria compartida. 

El paso de mensajes esta orientado a los sistemas distribuidos y 
la sincronizacion se alcanza mediante el uso de dos primitivas basi- 
cas: i) el envio y ii) la recepcion de mensajes. Asi, es posible establecer 
esquemas basados en la recepcion bloqueante de mensajes, de mane- 
ra que un proceso se quede bloqueado hasta que reciba un mensaje 
determinado. 

Ademas de discutir los conceptos fundamentales de este mecanis- 
mo de sincronizacion, en este capitulo se estudian las primitivas PO- 
SIX utilizadas para establecer un sistema de paso de mensajes me- 
diante las denominadas colas de mensajes POSIX [POSIX Message 
Queues). 

Finalmente, este capitulo plantea algunos problemas clasicos de 
sincronizacion en los que se utiliza el paso de mensajes para ob tener 
una solucion que gestione la ejecucion concurrente de los mismos y el 
problema de la seccion critica, estudiado en el capitulo 1 . 
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3. 1 . Conceptos basicos 

Dentro del ambito de la programacion concurrente, el paso de men- 
sajes representa un mecanismo basico de comunicacion entre proce- 
sos basado, principalmente, en el envio y recepcion de mensajes. 

En realidad, el paso de mensajes representa una abstraccion del 
concepto de comunicacion que manejan las personas, representado 
por mecanismos concretos como por ejemplo el correo electronico. La 
comunicacion entre procesos (InterProcess Communication, IPC) se 
basa en esta filosofia. El proceso emisor genera un mensaje como un 
bloque de informacion que responde a un determinado formato. El 
sistema operativo copia el mensaje del espacio de direcciones del emi- 
sor en el espacio de direcciones del proceso receptor, tal y como se 
muestra en la figura 3. 1. 

En el contexto del paso de mensajes, es importante recordar que 
un emisor no puede copiar informacion, directamente, en el espacio de 
direcciones de otro proceso receptor. En realidad, esta posibilidad esta 
reservada para el software en modo supervisor del sistema operativo. 

En su lugar, el proceso emisor pide que el sistema operativo entre- 
gue un mensaje en el espacio de direcciones del proceso receptor utili- 
zando, en algunas situaciones, el identificador unico o PID del proceso 
receptor. Asi, el sistema operativo hace uso de ciertas operaciones de 
copia para alcanzar este objetivo: i) recupera el mensaje del espacio de 
direcciones del emisor, ii) lo coloca en un buffer del sistema operativo 
y iii) copia el mensaje de dicho buffer en el espacio de direcciones del 
receptor. 

A diferencia de lo que ocurre con los sistemas basados en el uso de 
semaforos y segmentos de memoria compartida, en el caso de los siste- 
mas en paso de mensajes el sistema operativo facilita los mecanismos 
de comunicacion y sincronizacion sin necesidad de utilizar objetos de 
memoria compartida. En otras palabras, el paso de mensajes permite 
que los procesos se envien informacion y, al mismo tiempo, se sincro- 
nicen. 

Desde un punto de vista general, los sistemas de paso de mensajes 
se basan en el uso de dos primitivas de comunicacion: 

■ Envio (send), que permite el envio de informacion por parte de 
un proceso. 

■ Recepcion (receive), que permite la recepcion de informacion por 
parte de un proceso. 

Tipicamente, y como se discutira en la seccion 3.1.3, la sincroni- 
zacion se suele plantear en terminos de llamadas bloqueantes, cuya 
principal implicacion es el bloqueo de un proceso hasta que se satis- 
faga una cierta restriccion (por ejemplo, la recepcion de un mensaje). 
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Espacio de direcciones 
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Mecanismo de comunicacion 
entre procesos (IPC) del 
sistema operativo 
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Figura 3.1: Uso de mensajes para compartir informacion entre procesos. 



3.1.1. El concepto de buzon o cola de mensajes 

Teniendo en cuenta la figura 3. 1, el lector podria pensar que el en- 
vio de un mensaje podria modificar el espacio de direcciones de un 
proceso receptor de manera espontanea sin que el propio receptor es- 
tuviera al corriente. Esta situacion se puede evitar si no se realiza una 
copia en el espacio de direcciones del proceso receptor hasta que este 
no la solicite de manera explicita (mediante una primitiva de recep- 
cion). 

Ante esta problematica, el sistema operativo puede almacenar men- 
sajes de entrada en una cola o buzon de mensajes que actua como 
buffer previo a la copia en el espacio de direcciones del receptor. La 
figura 3.2 muestra de manera grafica la comunicacion existente entre 
dos procesos mediante el uso de un buzon o cola de mensajes. 



3.1.2. Aspectos de diseno en sistemas de mensajes 

En esta seccion se discuten algunos aspectos de diseno [13] que 
marcan el funcionamiento basico de un sistema basado en mensajes. 
Es muy importante conocer que mecanismo de sincronizacion se utili- 
zara a la hora de manejar las primitivas send y receive, con el objetivo 
de determinar si las llamadas a dichas primitivas seran bloqueantes. 



Sincronizacion 

La comunicacion de un mensaje entre dos procesos esta asociada 
a un nivel de sincronizacion ya que, evidentemente, un proceso A no 
puede recibir un mensaje hasta que otro proceso B lo envia. En este 
contexto, se plantea la necesidad de asociar un comportamiento a un 
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send () 



Proceso 




receive () 



Proceso 



Cola de mensajes 



Figura 3.2: Esquema de paso de mensajes basado en el uso de colas o buzones de 
mensajes. 



proceso cuando envia y recibe un mensaje. 

Por ejemplo, cuando un proceso recibe un mensaje mediante una 
primitiva de recepcion. existen dos posibilidades: 

■ Si el mensaje ya fue enviado por un proceso emisor, entonces el 
receptor puede obtener el mensaje y continuar su ejecucion. 

■ Si no existe un mensaje por obtener, entonces se plantean a su 
vez dos opciones: 

• Que el proceso receptor se bloquee hasta que reciba el men- 
saje. 

• Que el proceso receptor continue su ejecucion obviando, al 
menos temporalmente, el intento de recepcion. 

Del mismo modo, la operacion de envio de mensajes se puede plan- 
tear de dos formas posibles: 

■ Que el proceso emisor se bloquee hasta que el receptor reciba el 
mensaje. 

■ Que el proceso emisor no se bloquee y se aisle, al menos tempo- 
ralmente 1 , del proceso de recepcion del mensaje 

En el ambito de la programacion concurrente, la primitiva send se 
suele utilizar con una naturaleza no bloqueante, con el objetivo de que 
un proceso pueda continuar su ejecucion y, en consecuencia, pueda 
progresar en su trabajo. Sin embargo, este esquema puede fomentar 
practicas no deseables, como por ejemplo que un proceso envie men- 
sajes de manera continuada sin que se produzca ningun tipo de pe- 
nalizacion, asociada a su vez al bloqueo del proceso emisor. Desde el 
punto de vista del programador, este esquema hace que el propio pro- 
gramador sea el responsable de comprobar si un mensaje se recibio 
de manera adecuada, complicando asi la logica del programa. 

En el caso de la primitiva receive, la version bloqueante suele ser 
la elegida con el objetivo de sincronizar procesos. En otras palabras, 



Consldere el uso de un esquema basado en retrollamadas o notlficaclones 
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Figura 3.3: Aspectos basicos de diseno en sistemas de paso de mensajes para la comu- 
nicacion y sincronizacion entre procesos. 

un proceso que espera un mensaje suele necesitar la informacion con- 
tenida en el mismo para continuar con su ejecucion. Un problema que 
surge con este esquema esta derivado de la perdlda de un mensaje, 
ya que el proceso receptor se quedaria bloqueado. Dicho problema se 
puede abordar mediante una naturaleza no bloqueante. 

Direccionamiento 

Desde el punto de vista del envio y recepcion de mensajes, resulta 
muy natural enviar y reclbir mensajes de manera selectiva, es decir, 
especificando de manera explicita que proceso enviara un mensaje y 
que proceso lo va a recibir. Dicha informacion se podria especificar en 
las propias primitivas de envio y recepcion de mensajes. 

Este tipo de direccionamiento de mensajes recibe el nombre de di- 
reccionamiento directo, es decir, la primitiva send contiene un iden- 
tificador de proceso vinculado al proceso emisor. En el caso de la pri- 
mitiva receive se plantean dos posibilidades: 



Recuperacion por tipo 



Tambien es posible plantear 
un esquema basado en la re- 
cuperacion de mensajes por 
tipo, es decir, una recupera- 
cion selectiva atendiendo al 
contenido del propio mensa- 
je. 



1 . Designar de manera explicita al proceso emisor para que el pro- 
ceso receptor sepa de quien recibe mensajes. Esta alternativa 
suele ser la mas eficaz para procesos concurrentes cooperatives. 

2. Hacer uso de un direccionamiento directo implicito, con el obje- 
tivo de modelar situaciones en las que no es posible especificar, 
de manera previa, el proceso de origen. Un posible ejemplo seria 
el proceso responsable del servidor de impresion. 
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El otro esquema general es el direccionamiento indirecto, es de- 

cir, mediante este esquema los mensajes no se envian directamente 
por un emisor a un receptor, sino que son enviados a una estructura 
de datos compartida, denominada buzon o cola de mensajes, que al- 
macenan los mensajes de manera temporal. De este modo, el modelo 
de comunicacion se basa en que un proceso envia un mensaje a la 
cola y otro proceso toma dicho mensaje de la cola. 

La principal ventaja del direccionamiento indirecto respecto al di- 
recto es la flexibilidad, ya que existe un desacoplamiento entre los 
emisores y receptores de mensajes, posibilitando asi diversos esque- 
mas de comunicacion y sincronizacion: 



■ uno a uno, para llevar a cabo una comunicacion privada entre 
procesos. 

■ muchos a uno, para modelar situaciones cliente/servidor. En es- 
te caso, el buzon se suele conocer como puerto. 

■ uno a muchos, para modelar sistemas de broadcast o difusion de 
mensajes. 

■ muchos a muchos, para que multiples clientes puedan acceder a 
un servicio concurrente proporcionado por multiples servidores. 

Finalmente, es importante considerar que la asociacion de un pro- 
ceso con respecto a un buzon puede ser estatica o dinamica. Asi mis- 
mo, el concepto de propiedad puede ser relevante para establecer re- 
laciones entre el ciclo de vida de un proceso y el ciclo de vida de un 
buzon asociado al mismo. 



Formato de mensaje 



Tipo de mensaje 



PID origen 



Longitud del mensaje 



Contenido 



El formato de un mensaje esta directamente asociado a la funcio- 
nalidad proporcionada por la biblioteca de gestion de mensajes y al 
ambito de aplicacion, entendiendo dmbito como su uso en una unica 
maquina o en un sistema distribuido. En algunos sistemas de paso de 
mensajes, los mensajes tienen una longitud fija con el objetivo de no 
sobrecargar el procesamiento y almacenamiento de informacion. En 
otros, los mensajes pueden tener una longitud variable con el objeti- 
vo de incrementar la flexibilidad. 

En la figura 3.4 se muestra el posible formato de un mensaje ti- 
pico, distinguiendo entre la cabecera y el cuerpo del mensaje. Como 
se puede apreciar, en dicho mensaje van incluidos los identificadores 
unicos de los procesos emisor y receptor, conformando asi un direc- 
cionamiento directo explicito. 



Figura 3.4: Formato tlpico 
de un mensaje, estructura- 
do en cabecera y cuerpo. Co- 
mo se puede apreciar en la 
imagen, la cabecera contle- 
ne Informacion baslca para, 
por ejemplo, establecer un 
esquema dlnamico asociado 
a la longitud del contenido 
del mensaje. 



Disciplina de cola 

La disciplina de cola se refiere a la implementacion subyacente que 
rige el comportamiento interno de la cola. Tipicamente, las colas o bu- 
zones de mensajes se implementan haciendo uso de una cola FIFO 
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(First-In First-Out), es decir, los mensajes primeros en salir son aque- 
llos que llegaron en primer lugar. 

Sin embargo, es posible utilizar una disciplina basada en el uso 
de un esquema basado en prioridades, asociando un valor numeri- 
co de importancia a los propios mensajes para establecer politicas de 
ordenacion en base a los mismos. 



SECCION_ENTRADA 



SECCION^SALIDA 



SECCION.RESTANTE 



[while (1); 

Figura 3.5: Vision grafica del 
problema general de la sec- 
cion critica, dlstinguiendo la 
seccion de entrada, la propia 
seccion critica, la seccion de 
sallda y la seccion restante. 



3.1.3. El problema de la seccion critica 

El problema de la seccion critica, introducido en la seccion 1.2.2, 
se puede resolver facilmente utilizando el mecanismo del paso de men- 
sajes, tal y como muestra la figura 3.6. 



do 



receive (buzon, &msg) 



m 




| SECCION_RESTANTE j 



while (1) ; 



Figura 3.6: Mecanismo de exclusion mutua basado en el uso de paso de mensajes. 



Basicamente, es posible modelar una solucion al problema de la 
seccion critica mediante la primitiva receive bloqueante. Asi, los pro- 
cesos comparten un unico buzon, inicializado con un unico mensaje, 
sobre el que envian y reciben mensajes. Un proceso que desee acce- 
der a la seccion critica accedera al buzon mediante la primitiva receive 
para obtener un mensaje. En esta situacion se pueden distinguir dos 
posibles casos: 

1. Si el buzon esta vacio, entonces el proceso se bloquea. Esta si- 
tuacion implica que, de manera previa, otro proceso accedio al 
buzon y recupero el unico mensaje del mismo. El primer proceso 
se quedara bloqueado hasta que pueda recuperar un mensaje del 
buzon. 

2. Si el buzon tiene un mensaje, entonces el proceso lo recupera y 
puede acceder a la seccion critica. 

En cualquier caso, el proceso ha de devolver el mensaje al buzon en 
su seccion de salida para garantizar que el resto de procesos puedan 
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acceder a su seccion critica. En esencia, el unico mensaje del buzon se 
comporta como un token o testigo que gestiona el acceso exclusive* a 
la seccion critica. Es importante destacar que si existen varios proce- 
sos bloqueados a la espera de un mensaje en el buzon, entonces solo 
uno de ellos se desbloqueara cuando otro proceso envie un mensaje 
al buzon. No es posible conocer a priori que proceso se desbloqueara 
aunque, tipicamente, las colas de mensajes se implementan median- 
te colas FIFO (first-in first-out) , por lo que aqu ellos procesos que se 
bloqueen en primer lugar seran los primeros en desbloquearse. 

Desde un punto de vista semantico, el uso de un mecanismo ba- 
sado en el paso de mensajes para modelar el problema de la seccion 
critica es identico al uso de un mecanismo basado en semaforos Si se 
utiliza un semaforo para gestionar el acceso a la seccion critica, este 
ha de inicializarse con un valor igual al numero de procesos que pue- 
den acceder a la seccion critica de manera simultanea. Tipicamente, 
este valor sera igual a uno para proporcionar un acceso exclusive 

Si se utiliza el paso de mensajes, entonces el programador tendra 
que inicializar el buzon con tantos mensajes como procesos puedan 
acceder a la seccion critica de manera simultanea (uno para un acceso 
exclusivo). La diferencia principal reside en que la inicializacion es una 
operacion propia del semaforo, mientras que en el paso de mensajes 
se ha de utilizar la primitiva send para rellenar el buzon y, de este 
modo, llevar a cabo la inicializacion del mismo. 



3.2. Implement acion 



En esta seccion se discuten las primitivas POSIX mas importan- 
tes relativas al paso de mensajes. Para ello, POSIX proporciona las 
denominadas colas de mensajes (POSIX Message Queues). 

En el siguiente listado de codigo se muestra la primitiva mq_open(), 
utilizada para abrir una cola de mensajes existente o crear una nueva. 
Como se puede apreciar, dicha primitiva tiene dos versiones. La mas 
completa incluye los permisos y una estructura para definir los atri- 
butos, ademas de establecer el nombre de la cola de mensajes y los 
flags. 

Si la primitiva mq_open(j abre o crea una cola de mensajes de ma- 
nera satisfactoria, entonces devuelve el descriptor de cola asociada a 
la misma. Si no es asi, devuelve -1 y establece errno con el error ge- 
nerado. 



Compilation 



Utilice los flags adecuados 
en cada caso con el objetlvo 
de detectar la mayor canti- 
dad de errores en tlempo de 
compilation (e.g. escrlbir so- 
bre una cola de mensajes de 
solo lectura). 
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Las colas de mensajes en POSIX han de empezar por el caracter 
'/', como por ejemplo '/BuzonMensajesl'. 



Al igual que ocurre con los semaforos nombrados, las colas de men- 
sajes en POSIX se basan en la definicion de un nombre especifico para 
llevar a cabo la operacion de apertura o creacion de una cola. 



Listado 3.1: Primitiva mq open en POSIX. 



finclude <fcntl.h> /* Para constantes 0_* */ 

2 #include <sys/5tat.h> /* Para los permisos */ 
#include <mqueue.h> 

4 

5 /* Devuelve el descriptor de la cola de mensajes */ 

6 /* o — 1 si hubo error (ver errno) */ 
mqd_t mq_open ( 



const char tname, /* Nombre de la cola */ 

int oflag /* Flags (menos 0\_CREAT) */ 

10 ) ; 

11 mqd_t mq_open ( 

12 const char *name, /* Nombre de la cola */ 

int oflag /* Flags (incluyendo 0\_CREAT) */ 

14 mode_t perms, /* Permisos */ 

struct mq_attr *attr /* Atributos (o NULL) */ 

16 ) ; 



En el siguiente listado de codigo se muestra un ejemplo especifico 
de creacion de una cola de mensajes en POSLX. En las lineas (6-7) se 
definen los atributos basicos del buzon: 

■ mq_maxmsg, que define el maximo numero de mensajes. 

■ mq_msgsize, que establece el tamano maximo de mensaje. 

Ademas de la posibilidad de establecer aspectos basicos relativos a 
una cola de mensajes a la hora de crearla, como el tamano maximo 
del mensaje, es posible obtenerlos e incluso establecerlos de manera 
explicita, como se muestra en el siguiente listado de codigo. 



Listado 3.2: Obtencion/modificacion de atributos en una cola de 
mensajes en POSIX. 



finclude <mqueue.h> 

2 

int mq_getattr ( 

mqd_t mqdes, /* Descriptor de la cola */ 

struct mq_attr *attr /* Atributos */ 

6 ) ; 

7 

int mq_setattr ( 

mqd_t mqde s , 

10 struct mq_attr tnewattr, 

11 struct mq_attr *oldattr 

12 ) ; 



/ * Descriptor de la cola */ 
/ * Nuevos atributos */ 
/* Antiguos atributos */ 
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Por otra parte, en la linea (To] se lleva a cabo la operacion de crea- 
cion de la cola de mensajes, identificada por el nombre /prueba y sobre 
la que el proceso que la crea podra llevar a cabo operaciones de lectura 
(recepcion) y escritura (envio). Note como la estructura relativa a los 
atributos previamente comentados se pasa por referenda. Finalmen- 
te, en las lineas ( 14-17) se lleva a cabo el control de errores basicos a la 
hora de abrir la cola de mensajes. 

Las primitivas relativas al cierre y a la eliminacion de una cola 
de mensajes son muy simples y se muestran en el siguiente listado de 
codigo. La primera de ellas necesita el descriptor de la cola, mientras 
que la segunda tiene como parametro unico el nombre asociado a la 
misma. 



Listado 3.3: Ejemplo de creacion de una cola de mensajes en POSIX. 



1 /* Descriptor de cola de mensajes */ 

2 mqd_t qHandler; 
int rc; 

struct mq_at.tr mqAttr; /* Estructura de atributos */ 

5 

6 mqAttr . mq_maxmsg = 10; /* Maximo no de mensajes */ 

7 mqAttr ,mq_msgsize = 1024; /* Tamario maximo de mensaje */ 
8 

9 /* Creacion del buzon */ 

qHandler = mq_open (' /prueba' , 0_RDWR | 0_CREAT, 
S_IWUSR I S_IRUSR, SmqAttr) ; 

12 

13 /* Manejo de errores */ 

14 if (qHandler == -1) { 

15 fprintf (stderr, "%s\n", strerror (errno) ) ; 

16 exit (EXIT_FAILURE) ; 

17 } 



Desde el punto de vista de la programacion concurrente, las pri- 
mitivas mas relevantes son las de envio y recepcion de mensajes, ya 
que permiten no solo sincronizar los procesos sino tambien compar- 
tir informacion entre los mismos. En el siguiente listado de codigo se 
muestra la signatura de las primitivas POSIX send y receive. 



Listado 3.4: Primitivas de cierre y eliminacion de una cola de men- 
sajes en POSIX. 



#include <mqueue.h> 

2 

3 int mq_close ( 

mqd_t mqdes /* Descriptor de la cola de mensajes */ 

) ; 

6 

int mq_unlink ( 

const char *name /* Nombre de la cola */ 

) ; 



Por una parte, la primitiva send permite el envio del mensaje de- 
finido por msg_ptr, y cuyo tamario se especifica en msg_len, a la cola 
asociada al descriptor especificado por mqdes. Es posible asociar una 
prioridad a los mensajes que se envian a una cola median te el para- 
metro msg_prio. 
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Por otra parte, la primitiva receive per mite recibir mensajes de una 
cola. Note como los parametros son practicamente los mismos que los 
de la primitiva send. Sin embargo, ahora msg_ptr representa el buffer 
que almacenara el mensaje a recibir y msg_len es el tamano de dicho 
buffer. Ademas, la primitiva de recepcion implica obtener la prioridad 
asociada al mensaje a recibir, en lugar de especificarla a la hora de 
enviarlo. 



Listado 3.5: Primitivas de envio y recepcion en una cola de mensajes 
en POSIX. 



#include <mqueue.h> 

int mq_send ( 

mqd_t mqde s , 
const char *msq_ptr, 
size_t msg_len, 
unsigned msg_prio 



/* Descriptor de la cola */ 

/* Mensaje */ 

/* Tamario del mensaje */ 

/* Prioridad */ 



ssize_t mq_receive ( 

11 mqd_t mqdes, 

12 char *msg_ptr, 

13 size_t msg_len, 
unsigned *msg_prio 

15 ) ; 



/ * Descriptor de la cola */ 

/* Buffer para el mensaje */ 

/* Tamario del buffer */ 

/* Prioridad o NULL */ 



El siguiente listado de codigo muestra un ejemplo muy representa- 
tivo del uso del paso de mensajes en POSIX, ya que refleja la recep- 
cion bloqueante, una de las operaciones mas representativas de este 
mecanismo. 

En las lineas ( 6-7 ) se refleja el uso de la primitiva receive, utilizando 
buffer como variable receptora del contenido del mensaje a recibir y 
prioridad para obtener el valor de la misma. Recuerde que la semantica 
de las operaciones de una cola, como por ejemplo que la recepcion 
sea no bloqueante, se definen a la hora de su creacion, tal y como 
se mostro en uno de los listados anteriores, mediante la estructura 
mq_attr. Sin embargo, es posible modificar y obtener los valores de 
configuracion asociados a una cola mediante las primitivas mq_setattr 
y mq_getattr, respectivamente. 



Listado 3.6: Ejemplo de recepcion bloqueante en una cola de mensa- 
jes en POSIX. 



mqd_t qHandler; 

2 int rc; 

3 unsigned int prioridad; 

4 char buffer [2048] ; 

5 

rc = mq_receive (qHandler, buffer, 

sizeof (buf f er ) , Sprioridad) ; 

8 

if (rc == -1) 

10 fprintf {stderr, "%s\n", strerror (errno) ) ; 

11 else 

12 printf {"Recibiendo mensaje: %s\n", buffer); 
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A El buffer de recepcion de mensajes ha de tener un tamano ma- 
yor o igual a mq msgsize, mientras que el buffer de envio de un 
mensaje ha de tener un tamano menor o igual a mq_msgsize. 



En el anterior listado tambien se expone como obtener informacion 
relativa a posibles errores mediante errno. En este contexto, el fichero 
de cabecera errno.h, incluido en la biblioteca estandar del lenguaje C, 
define una serie de macros para informar sobre condiciones de error, 
a traves de una serie de codigos de error, almacenados en un espacio 
estatico denominado errno. 

De este modo, algunas primitivas modifican el valor de este espa- 
cio cuando detectan determinados errores. En el ejemplo de recepcion 
de mensajes, si receive devuelve un codigo de error -1, entonces el 
programador puede obtener mas informacion relativa al error que se 
produjo, como se aprecia en las lineas [9-10] . 

El envio de mensajes, en el ambito de la programacion concurren- 
te, suele man tener una semantica no bloqueante, es decir, cuando un 
proceso envia un mensaje su flujo de ejecucion continua inmediata- 
mente despues de enviar el mensaje. Sin embargo, si la cola POSIXya 
estaba llena de mensajes, entonces hay que distinguir entre dos casos: 

1. Por defecto, un proceso se bloqueara al enviar un mensaje a una 
cola llena, hasta que haya espacio disponible para encolarlo. 

2. Si el flag 0_NONBLOCK esta activo en la descripcion de la cola 
de mensajes, entonces la llamada a send fallara y devolvera un 
codigo de error. 



En POSIX.. 



En el estandar POSIX, las 
primitivas mq_ttmedsend y 
mq_timedreceive permiten 
asociar timeouts para es- 
pecificar el tiempo maximo 
de bloqueo al utilizar las 
primitivas send y receive, 
respectivamente . 



El siguiente listado de codigo muestra un ejemplo de envio de 

mensajes a traves de la primitiva send. Como se ha comentado ante- 
riormente, esta primitiva de envio de mensajes se puede comportar de 
una manera no bloqueante cuando la cola esta llena de mensajes (ha 
alcanzado el mimero maximo definido por mq_maxmsg). 



Listado 3.7: Ejemplo de envio en una cola de mensajes en POSIX. 



mqd_t qHandler; 
int rc; 

3 unsigned int prioridad; 

4 char buffer [512] ; 
5 

6 sprintf (buffer, "[ Saludos de %d ]", getpidO); 
mq_send (qHandler, buffer, sizeof (buffer) , 1); 



Llegados a este punto, el lector se podria preguntar como es posi- 
ble incluir tipos o estructuras de datos especificas de un determi- 
nado dominio con el objetivo de intercambiar informacion entre varios 
procesos mediante el uso del paso de mensajes. Esta duda se podria 
plantear debido a que tanto la primitiva de envio como la primitiva 
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de recepcion de mensajes manejan cadenas de caracteres (punteros a 
char) para gestionar el contenido del mensaje. 

En realidad, este enfoque, extendido en diversos ambitos del estan- 
dar POSIX, permite manejar cualquier tipo de datos de una manera 
muy sencilla, ya que solo es necesario aplicar los moldes necesarios 
para enviar cualquier tipo de informacion. En otras palabras, el tipo 
de datos char * se suele utilizar como buffer generico, posibilitando el 
uso de cualquier tipo de datos definido por el usuario. 



Muchos APIs utilizan char * como buffer generico. Simplemen- 
te, considere un puntero a buffer, junto con su tamano, a la 
hora de manejar estructuras de datos como contenido de men- 
saje en las primitivas send y receive. 



El siguiente listado de codigo muestra un ejemplo representative de 
esta problematica. Como se puede apreciar, en dicho ejemplo el buffer 
utilizado es una estructura del tipo TData, definida por el usuario. 
Note como al usar las primitivas send y receive se hace uso de los 
moldes correspondientes para cumplir con la especificacion de dichas 
primitivas. 



Listado 3.8: Uso de tipos de datos especificos para manejar mensajes. 



typedef struct { 

2 int valor; 
} TData; 

4 

TData buffer; 

6 

7 /* Atributos del buzon */ 

8 mqAttr . mq_maxmsg = 10; 

9 mqAttr . mq_msgsize = sizeof (TData) ; 
10 

11 /* Recepcion */ 

mq_receive (qHandler, (char *)&buffer, 

sizeof (buff er) , Sprioridad) ; 

14 /* Envio */ 

mq_send (qHandler , (const char *)&buffer, 
16 sizeof (buff er) , 1) ; 



Finalmente, el estandar POSIX tambien define la primitiva mq_notify 
en el contexto de las colas de mensajes con el objetivo de notificar a 
un proceso o hilo, mediante una senal, cuando llega un mensaje. 

Basicamente, esta primitiva permite que cuando un proceso o un 
hilo se registre, este reciba una senal cuando llegue un mensaje a una 
cola vacia especificada por mqdes, a menos que uno o mas procesos 
o hilos ya esten bloqueados mediante una llamada a mq_receive. En 
esta situacion, una de estas llamadas a dicha primitiva retornara en 
su lugar. 
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Listado 3.9: Primitiva mq_notify en POSIX. 



#include <mqueue.h> 

2 

int mq_notify ( 



4 /* Descriptor de la cola */ 

5 mqd_t mqdes, 

6 /* Estructura de notif icacion 

7 Contiene funciones de retrollamada 

para notificar la llegada de un nuevo mensaje */ 
const struct sigevent *sevp 



10 ) ; 



3.2.1. El problema del bloqueo 

El uso de distintas colas de mensajes, asociado al manejo de dis- 
tintos tipos de tareas o de distintos tipos de mensajes, por parte de 
un proceso que maneje una semantica de recepcion bloqueante puede 
dar lugar al denominado problema del bloqueo. 

Suponga que un proceso ha sido disenado para atender peticiones 
de varios buzones, nombrados como Ay B. En este contexto, el proceso 
se podria bloquear a la espera de un mensaje en el buzon A. Mientras 
el proceso se encuentra bloqueado, otro mensaje podria llegar al buzon 
B. Sin embargo, y debido a que el proceso se encuentra bloqueado en 
el buzon A, el mensaje almacenado en B no podria ser atendido por 
el proceso, al menos hasta que se desbloqueara debido a la nueva 
existencia de un mensaje en A. 



@^C6mo es posible atender distintas peticiones (tipos de tareas) 
de manera eficiente por un conjunto de procesos? 



Esta problematica es especialmente relevante en las colas de men- 
sajes POSIX, donde no es posible llevar a cabo una recuperacion se- 
lectiva por tipo de mensaje 2 . 

Existen diversas soluciones al problema del bloqueo. Algunas de 
ellas son especificas del interfaz de paso de mensajes utilizado, mien- 
tras que otras, como la que se discutira a continuacion, son generales 
y se podrian utilizar con cualquier sistema de paso de mensajes. 

Dentro del contexto de las situaciones especificas de un sistema de 
paso de mensajes, es posible utilizar un esquema basado en recupe- 
racion selectiva, es decir, un esquema que permite que los procesos 
obtengan mensajes de un buzon en base a un determinado criterio. 
Por ejemplo, este criterio podria definirse en base al tipo de mensaje, 
codificado mediante un valor numerico. Otro criterio mas exclusivo po- 
dria ser el propio identificador del proceso, planteando asi un esquema 
estrechamente relacionado con una comunicacion directa. 



2 En System V IPC, es posible recuperar mensajes de un buzon indicando un tipo. 
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No obstante, el problema de la recuperacion selectiva solo solventa 
el problema del bloqueo parcialmente ya que no es posible conocer 
a priori si un proceso se bloqueara ante la recepcion (con semantica 
bloqueante) de un mensaje asociado a un determinado tipo. 

Otra posible opcion especifica, en este caso incluida en las colas de 
mensajes de POSIX, consiste en hacer uso de algun tipo de esquema de 
notificacion que sirva para que un proceso sepa cuando se ha recibido 
un mensaje en un buzon especifico. En el caso particular de POSIX, 
la operacion mq_notify permite, previo registro, que un proceso o hilo 
reciba una serial cuando un mensaje llegue a un determinado buzon. 

Desde el punto de vista de las soluciones generales, en la seccion 
5.18 de [9] se discute una solucion al problema del bloqueo denomina- 
da Unified Event Manager (gestor de eventos unificado). Basicamen- 
te, este enfoque propone una biblioteca de funciones que cualquier 
aplicacion puede usar. Asi, una aplicacion puede registrar un evento, 
causando que la biblioteca cree un hilo que se bloquea. La aplicacion 
esta organizada alrededor de una cola con un unico evento. Cuando 
un evento llega, la aplicacion lo desencola, lo procesa y vuelve al esta- 
do de espera. 

El enfoque general que se plantea en esta seccion se denomina 
esquema beeper (ver figura 3.7) y consiste en utilizar un buzon espe- 
cifico que los procesos consultaran para poder recuperar informacion 
relevante sobre la proxima tarea a acometer. 



a 



El esquema beeper planteado en esta seccion se asemeja al 
concepto de localizador o buscador de personas, de manera que 
el localizador notifica el numero de telefono o el identificador de 
la persona que esta buscando para que la primera se pueda 
poner en contacto. 



Por ejemplo, un proceso que obtenga un mensaje del buzon beeper 
podra utilizar la informacion contenido en el mismo para acceder a 
otro buzon particular. De este modo, los procesos tienen mas informa- 
cion para acometer la siguiente tarea o procesar el siguiente mensaje. 

En base a este esquema general, los procesos estaran bloqueados 
por el buzon beeper a la hora de recibir un mensaje. Cuando un pro- 
ceso lo reciba y, por lo tanto, se desbloquee, entonces podra utilizar 
el contenido del mensaje para, por ejemplo, acceder a otro buzon que 
le permita completar una tarea. En realidad, el uso de este esquema 
basado en dos niveles evita que un proceso se bloquee en un buzon 
mientras haya tareas por atender en otro. 

Asi, los procesos estaran tipicamente bloqueados mediante la pri- 
mitiva receive en el buzon beeper. Cuando un cliente requiera que uno 
de esos procesos atienda una peticion, entonces enviara un mensaje al 
buzon beeper indicando en el contenido el tipo de tarea o el nuevo bu- 
zon sobre el que obtener informacion. Uno de los procesos bloqueados 
se desbloqueara, consultara el contenido del mensaje y, posteriormen- 
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Buzon Beeper 




Buzon Beeper 



Proceso 




Buzon A 



> 



Proceso 



***** 



0 



Buzon B 



Proceso 



Figura 3.7: Mecanismo de notiiicacion basado en un buzon o cola tipo beeper para 
gestionar el problema del bloqueo. 



te, realizara una tarea o accedera al buzon indicado en el contenido del 
mensaje enviado al beeper. 



3.3. Problemas clasicos de sincronizacion 

En esta seccion se plantean varios problemas clasicos de sincroni- 
zacion, algunos de los cuales ya se han planteado en la seccion 2.3, 
y se discuten como podrian solucionarse utilizando el mecanismo del 
paso de mensajes. 
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3.3.1. El buffer limitado 



El problema del buffer limitado o problema del productor / consumi- 
dor, introducido en la seccion 1.2.1, se puede resolver de una forma 
muy sencilla utilizando un unico buzon o cola de mensajes. Recuerde 
que en la seccion 2.3.1 se planteo una solucion a este problema uti- 
lizando dos semaforos contadores para controlar, respectivamente, el 
numero de huecos llenos y el numero de huecos vacios en el buffer. 

Sin embargo, la solucion mediante paso de mensajes es mas sim- 
ple, ya que solo es necesario utilizar un unico buzon para controlar 
la problematica subyacente. Basicamente, tan to los productores como 
los consumidores comparten un buzon cuya capacidad esta determi- 
nada por el numero de huecos del buffer. 



while (1) { 

// Producir . . . 
producir ( ) ; 
// Nuevo item . . . 
send (buzon, msg); 

} 



while (1) { 

recibir (buzon, &msg) 
// Consumir . . . 
consumir ( ) ; 



} 



Figura 3.8: Solucion al problema del buffer limitado mediante una cola de mensajes. 



Inicialmente, el buzon se rellena o inicializa con tantos mensajes 
como huecos ocupados haya originalmente, es decir, 0. Tan to los pro- 
ductores como los consumidores utilizan una semantica bloqueante, 
de manera que 

■ Si un productor intenta insertar un elemento con el buffer lleno, 
es decir, si intenta enviar un mensaje al buzon lleno, entonces se 
quedara bloqueado a la espera de un nuevo hueco (a la espera de 
que un consumidor obtenga un item del buffer y, en consecuen- 
cia, un mensaje de la cola). 

■ Si un consumidor intenta obtener un elemento con el buffer va- 
cio, entonces se bloqueara a la espera de que algun consumidor 
inserte un nuevo elemento. Esta situacion se modela mediante la 
primitiva de recepcion bloqueante. 

Basicamente, la cola de mensajes permite modelar el comporta- 
miento de los procesos productor y consumidor mediante las primiti- 
vas basicas de envio y recepcion bloqueantes. 
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3.3.2. Los filosofos comensales 



El problema de los filosofos comensales, discutido en la seccion 
2.3.3, tambien se puede resolver de una manera sencilla utilizando el 
paso de mensajes y garantizando incluso que no haya un interbloqueo. 

Al igual que ocurria con la solucion basada en el uso de semafo- 
ros, la solucion discutida en esta seccion maneja un array de palillos 
para gestionar el acceso exclusivo a los mismos. Sin embargo, ahora 
cada palillo esta representado por una cola de mensajes con un unico 
mensaje que actua como token o testigo entre los filosofos. En otras 
palabras, para que un filosofo pueda obtener un palillo, tendra que 
recibir el mensaje de la cola correspondiente. Si la cola esta vacia, en- 
tonces se quedara bloqueado hasta que otro filosofo envie el mensaje, 
es decir, libere el palillo. 

En la figura 3. 10 se muestra el pseudocodigo de una posible solu- 
cion a este problema utilizando paso de mensajes. Note como se utiliza 
un array, denominado palillo, donde cada elemento de dicho array re- 
presenta un buzon de mensajes con un unico mensaje. 




Figura 3.9: Esquema grafi- 
co del problema original de 
los filosofos comensales {di- 
ning philosophers). 



Proceso filosofo 



while (1) { 

/* Pensar ... */ 
receive (mesa, &m) ; 
receive (palillo [i] , &m) ; 
receive (palillo [i + 1 ] , &m) ; 
/ * Comer ... * / 
send (palillo [i] , m) ; 
send (palillo [i+1] , m) ; 
send (mesa, m) ; 



Figura 3.10: Solucion al problema de los filosofos comensales (sin Interbloqueo) me- 
diante una cola de mensajes. 



Por otra parte, la solucion planteada tambien hace uso de un bu- 
zon, denominado mesa, que tiene una capacidad de cuatro mensajes. 
Inicialmente, dicho buzon se rellena con cuatro mensajes que repre- 
sentan el numero maximo de filosofos que pueden coger palillos cuan- 
do se encuentren en el estado hambriento. El objetivo es evitar una 
situacion de interbloqueo que se podria producir si, por ejemplo, to- 
dos los filosofos cogen a la vez el palillo que tienen a su izquierda. 

Al manejar una semantica bloqueante a la hora de recibir mensajes 
(intentar adquirir un palillo), la solucion planteada garantiza el acceso 
exclusivo a cada uno de los palillos por parte de un unico filosofo. La 
accion de dejar un palillo sobre la mesa esta representada por la primi- 
tiva send, posibilitando asi que otro filosofo, probablemente bloqueado 
por receive, pueda adquirir el palillo para comer. 
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Tabaco Papel Fosforos 



Tabaco 

Papel 

Fosforos 




Figura 3.11: Esquema grafico del problema de los fumadores de cigarrillos. 

En el anexo B se muestra una implementacion al problema de los 
filosofos comensales utilizando las colas de mensajes POSIX. En dicha 
implementacion, al igual que en la solucion planteada en la presente 
seccion, se garantiza que no exista un interbloqueo entre los filosofos. 

3.3.3. Los fumadores de cigarrillos 

El problema de los fumadores de cigarrillos es otro problema clasi- 
co de sincronizacion. Basicamente, es un problema de coordinacion 
entre un agente y tres fumadores en el que intervienen tres ingredien- 
tes: i) papel, ii) tabaco y iii) fosforos. Por una parte, el agente dispone 
de una cantidad ilimitada respecto a los tres ingredientes. Por otra 
parte, cada fumador dispone de un unico elemento, tambien en canti- 
dad ilimitada, es decir, un fumador dispone de papel, otro de tabaco y 
otro de fosforos. 

Cada cierto tiempo, el agente coloca sobre una mesa, de manera 
aleatoria, dos de los tres ingredientes necesarios para liarse un ciga- 
rrillo (ver figura 3.11). El fumador que tiene el ingrediente restante 
coge los otros dos de la mesa, se lia el cigarrillo y se lo notifica al 
agente. Este ciclo se repite indefinidamente. 

La problematica principal reside en coordinar adecuadamente al 
agente y a los fumadores, considerando las siguientes acciones: 

1 . El agente pone dos elementos sobre la mesa. 

2. El agente notifica al fumador que tiene el tercer elemento que ya 
puede liarse un cigarrillo (se Simula el acceso del fumador a la 
mesa) . 
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Proceso agente 



Proceso fumador 



while (1) { 

/* Genera ingredientes */ 
restante = poner_ingredientes ( ) ; 
/* Notifica al fumador */ 
send (buzones [restante] , msg) ; 
/* Espera notificacion fumador */ 
receive (buzon_agente, &msg) ; 



while (1) { 



/* Espera ingredientes */ 
receive (mi_buzon, &msg) ; 
/ / Liando . . . 



liar_cigarrillo ( ) ; 



/* Notifica al agente */ 
send (buzon_agente , msg); 



Figura 3.12: Solucion en pseudocodigo al problema de los fumadores de cigarrillos 
usando paso de mensajes. 

3. El agente espera a que el fumador le notifique que ya ha termi- 
nado de liarse el cigarrillo. 

4. El fumador notifica que ya ha terminado de liarse el cigarrillo. 

5. El agente vuelve a poner dos nuevos elementos sobre la mesa, 
repitiendose asi el ciclo. 

Este problema se puede resolver utilizando dos posibles esquemas: 

■ Recuperacion selectiva utilizando un unico buzon (ver figura 
3. 13). En este caso, es necesario integrar en el contenido del men- 
saje de algun modo el tipo asociado al mismo con el objetivo de 
que lo recupere el proceso adecuado. Este tipo podria ser A, T, P 
o F en funcion del destinatario del mensaje. 

■ Recuperacion no selectiva utilizando multiples buzones (ver fi- 
gura 3.14). En este caso, es necesario emplear tres buzones para 
que el agente pueda comunicarse con los tres tipos de agentes 
y, adicionalmente, otro buzon para que los fumadores puedan 
indicarle al agente que ya terminaron de liarse un cigarrillo. 

Este ultimo caso de recuperacion no selectiva esta estrechamen- 
te ligado al planteamiento de las colas de mensajes POSIX, donde no 
existe un soporte explicito para llevar a cabo una recuperacion se- 
lectiva. En la figura 3.12 se muestra el pseudocodigo de una posible 
solucion atendiendo a este segundo esquema. 

Como se puede apreciar en la misma, el agente notifica al fumador 
que completa los tres ingredientes necesarios para fumar a traves de 
un buzon especifico, asociado a cada tipo de fumador. Posteriormente, 
el agente se queda bloqueado (mediante receive sobre buzon_agente) 
hasta que el fumador notifique que ya ha terminado de liarse el ci- 
garrillo. En esencia, la sincronizacion entre el agente y el fumador se 
realiza utilizando el patron rendezvous. 



Agente 




Figura 3.13: Solucion al pro- 
blema de los fumadores de 
cigarrillos con un unico bu- 
zon de recuperacion selecti- 
va. 





/l^lj — ^_r~ 


A 1^ 


■*\ B_P | P | 








1 B_A 1 



Figura 3.14: Solucion al pro- 
blema de los fumadores de 
cigarrillos con multiples bu- 
zones sin recuperacion selec- 
tiva (A= Agente, T=Fumador 
con tabaco, P=Fumador con 
papel, F=Fumador con fosfo- 
ros). 
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46 
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33 
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95 



Figura 3.15: Esquema con las correspondencias de traduccion. Por ejemplo, el carac- 
ter codificado con el valor 1 se corresponde con el codigo ASCII 97, que representa el 
caracter 'a'. 

3.3.4. Simulacion de un sistema de codificacion 

En esta seccion se propone un problema que no se encuadra dentro 
de los problemas clasicos de sincronizacion pero que sirve para afian- 
zar el uso del sistema de paso de mensajes para sincronizar procesos 
y comunicarlos. 

Basicamente, se pide construir un sistema que simule a un sen- 
cillo sistema de codificacion de caracteres por parte de una serie de 
procesos de traduccion. En este contexto, existira un proceso clien- 
te encargado de manejar la siguiente informacion: 

■ Cadena codificada a descodificar. 

■ Numero total de procesos de traduccion. 

■ Tamano maximo de subcadena a descodificar, es decir, tamafio 
de la unidad de trabajo maximo a enviar a los procesos de codifi- 
cacion. 

La cadena a descodificar estara formada por una secuencia de nu- 
meros enteros, entre 1 y 57, separados por puntos, que los procesos de 
traduccion tendran que traducir utilizando el sistema mostrado en la 
figura 3.15. El tamano de cada una de las subcadenas de traduccion 
vendra determinado por el tercer elemento mencionado en el listado 
anterior, es decir, el tamano maximo de subcadena a descodificar. 

Por otra parte, el sistema contara con un unico proceso de pun- 
tuacion, encargado de traducir los simbolos de puntuacion correspon- 
dientes a los valores enteros comprendidos en el rango 53-57, ambos 
inclusive. Asi, cuando un proceso de traduccion encuentre uno de es- 
tos valores, entonces tendra que enviar un mensaje al unico proceso 
de puntuacion para que este lo descodifique y, posteriormente, se lo 
envie al cliente mediante un mensaje. 

Los procesos de traduccion atenderan peticiones hasta que el clien- 
te haya enviado todas las subcadenas asociadas a la cadena de traduc- 
cion original. En la siguiente figura se muestra un ejemplo concreto 
con una cadena de entrada y el resultado de su descodificacion. 
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Figura 3.16: Ejemplo concreto de traduccion mediante el sistema de codificacion dis- 
cutido. 



La figura 3.17 muestra de manera grafica el diseno, utilizando colas 
de mensajes POSIX (sin recuperacion selectiva), planteado para solu- 
clonar el problema propuesto en esta seccion. Basicamente, se utilizan 
cuatro colas de mensajes en la solucion planteada: 

■ Buzon de traduccion, utilizado por el proceso cliente para enviar 
las subcadenas a descodificar. Los procesos de traduccion esta- 
ran bloqueados mediante una primitiva de recepcion sobre dicho 
buzon a la espera de trabajo. 

■ Buzon de puntuacion, utilizado por los procesos de traduccion 
para enviar mensajes que contengan simbolos de puntuacion al 
proceso de puntuacion. 

■ Buzon de notificacion. utilizado por el proceso de puntuacion 
para enviar la informacion descodificada al proceso de traduccion 
que solicito la tarea. 

■ Buzon de cliente, utilizado por los procesos de traduccion para 
enviar mensajes con subcadenas descodificadas. 

En la solucion planteada se ha aplicado el patron rendezvous en 
dos ocasiones para sincronizar a los distintos procesos involucrados. 
En concreto, 

■ El proceso cliente envia una serie de ordenes a los procesos de 
traduccion, quedando posteriormente a la espera hasta que haya 
obtenido todos los resultados parciales (mismo numero de orde- 
nes enviadas). 

■ El proceso de traduccion envia un mensaje al proceso de puntua- 
cion cuando encuentra un simbolo de traduccion, quedando a la 
espera, mediante la primitiva receive, de que este ultimo envie un 
mensaje con la traduccion solicitada. 

La figura 3.18 muestra una posible solucion en pseudocodigo con- 
siderando un sistema de paso de mensajes con recuperacion no selec- 
tiva. 
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Figura 3.17: Esquema grafico con la solucion planteada, utilizando un sistema de paso 
de mensajes, para sincronizar y comunicar a los procesos involucrados en la simulacion 
planteada. Las llneas punteadas Indlcan pasos opclonales (traduccion de srmbolos de 
puntuacion) . 



Como se puede apreciar, el proceso cliente es el responsable de 
obtener el numero de subvectores asociados a la tarea de traduccion 
para, posteriormente, enviar tantos mensajes a los procesos de tra- 
duccion como tareas haya. Una vez enviados los mensajes al buzon 
de traduccion, el proceso cliente queda a la espera, mediante la pri- 
mitiva de recepcion bloqueante, de los distintos resultados parciales. 
Finalmente, mostrara el resultado descodificado. 

Por otra parte, el proceso de traduccion permanece en un bucle 
infinito a la espera de algun trabajo, utilizando para ello la primitiva 
de recepcion bloqueante sobre el buzon de traduccion (utilizado por el 
cliente para enviar trabajos). Si un trabajo contiene un simbolo de tra- 
duccion, entonces el proceso de traduccion solicita ayuda al proceso 
de puntuacion mediante un rendezvous, utilizando el buzon de pun- 
tuacion. Si no es asi, entonces traduce el subvector directamente. En 
cualquier caso, el proceso de traduccion envia los datos descodificados 
al proceso cliente. 

Finalmente, el proceso de puntuacion tambien permanece en un 
bucle infinito, bloqueado en el buzon de puntuacion, a la espera de 
alguna tarea. Si la recibe, entonces la procesa y envia el resultado, 
mediante el buzon de notificacion, al proceso de traduccion que solici- 
to dicha tarea. 
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Proceso cliente 



obtener_datos (Sdatos) ; 
crear_buzones () ; 
lanzar_procesos () ; 

calcular_num_subv (datos , &num_sub) ; 

for i in range (0, num subv) { 
// Generar orden. 
generar_orden ( Sorden, datos); 
// Solicita traduccion. 
send(buzon traduccion, orden); 

} 

for i in range (0, num subv) { 
// Espera traduccion. 
receive (buzon cliente, &msg) ; 
actualizar (datos, msg); 

} 

mostrar_resultado (datos) ; 



Proceso traduccion 



while (1) { 

// Espera tarea . 

receive (buzon traduccion, Sorden) ; 

/ / Traduccion . . . 

if (es_simbolo (orden . datos ) ) { 

send (buzon_puntuacion, orden); 

receive (buzon notif icacion, Smsg) ; 

} 

else 

traducir ( Sorden, Smsg) ; 
// Notif ica traduccion. 
send (buzon cliente, msg) ; 



Proceso puntuacion 



while (1) { 

receive (buzon puntuacion, Sorden) ; 

traducir ( Sorden, Smsg) ; 

send (buzon notif icacion, msg) ; 



Figura 3.18: Solucion en pseudocodigo que muestra la funcionalidad de cada uno de 
los procesos del slstema de codificaclon. 



En este problema se puede apreciar la potencia de los sistemas 
de paso de mensajes, debido a que se pueden utilizar no solo para 
sincronizar procesos sino tambien para compartir informacion. 




cion, principalmente de un mayor nivel de abstraction, que 



1 4 se pueden utilizar en el ambito de la programacion concurren- 
te. Algunos de estos mecanismos mantienen la misma esencia que los 
ya estudiados anteriormente, como por ejemplo los semaforos, pero 
anaden cierta funcionalidad que permite que el desarrollador se abs- 
traiga de determinados aspectos problematicos. 

En concreto, en este capitulo se estudian soluciones vinculadas al 
uso de lenguajes de programacion que proporclonan un soporte nativo 
de concurrencia, como Ada, y el concepto de monitor como ejemplo 
representative de esquema de sincronizacion de mas alto nivel. 

Por una parte, el lector podra asimilar como Ada95 proporciona 
herramientas y elementos especificos que consideran la ejecucion con- 
currente y la sincronizacion como aspectos fundamentales, como es el 
caso de las tareas o los objetos protegidos. Los ejemplos planteados, 
como es el caso del problema de los filosofos comensales, permitiran 
apreciar las diferencias con respecto al uso de semaforos POSIX. 

Por otra parte, el concepto de monitor permitira comprender la 
importancia de soluciones de mas alto nivel que solventen algunas 
de las limitaciones que tienen mecanismos como el uso de semaforos 
y el paso de mensajes. En este contexto, se estudiara el problema 
del buffer limitado y como el uso de monitores permite plantear una 
solucion mas estructurada y natural. 
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4.1. Motivacion 

Los mecanismos de sincronizacion basados en el uso de semaforos 
y colas de mensajes estudiados en los capitulos 2 y 3, respectlvamente, 
presentan ciertas limitaciones que han motivado la creacion de otros 
mecanismos de sincronizacion que las solventen o las mitiguen. De 
hecho, hoy en dia existen lenguajes de programacion con un fuerte 
soporte nativo de concurrencia y sincronizacion. 

En su mayor parte, estas limitaciones estan vinculadas a la propia 
naturaleza de bajo nivel de abstraccion asociada a dichos mecanis- 
mos. A continuacion se discutira la problematica particular asociada 
al uso de semaforos y colas de mensajes como herramientas para la 
sincronizacion. 

En el caso de los semaforos, las principales limitaciones son las 
siguientes: 

■ Son propensos a errores de programacion. Por ejemplo, consi- 
dere la situacion en la que el desarrollador olvida liberar un se- 
maforo binario mediante la primitiva signal 

■ Proporcionan una baja flexibilidad debido a su naturaleza de 
bajo nivel. Recuerde que los semaforos se manejan unicamente 
mediante las primitivas wait y signal. 

Ademas, en determinados contextos, los semaforos pueden presen- 
tar el problema de la espera activa en funcion de la implementacion 
subyacente en primitivas como wait. Asi mismo, su uso suele estar 
asociado a la manipulacion de elementos desde un punto de vista glo- 
bal, presentando una problematica similar a la del uso de variables 
globales en un programa. 

Por otra parte, en el caso de las colas de mensajes, las principales 
limitaciones son las siguientes: 

■ No modelan la sincronizacion de forma natural para el progra- 
mador. Por ejemplo, considere el modelado de la exclusion mutua 
de varios procesos mediante una cola de mensajes con capacidad 
para un unico elemento. 

■ Al igual que en el caso de los semaforos, proporcionan una baja 
flexibilidad debido a su naturaleza de bajo nivel. Recuerde que 
las colas de mensajes se basan, esencialmente, en el uso de las 
primitivas send y receive. 

Este tipo de limitaciones, vinculadas a mecanismos de sincroniza- 
cion de bajo nivel como los semaforos y las colas de mensajes, han 
motivado la aparicion de soluciones de mas alto nivel que, desde el 
punto de vista del programador, se pueden agrupar en dos grandes 
categorias: 

■ Lenguajes de programacion con soporte nativo de concurrencia, 
como por ejemplo Ada o Modulo. 
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■ Bibliotecas externas que proporcionan soluciones, tipicamente 
de mas alto nivel que las ya estudiadas, al problema de la concu- 
rrencia, como por ejemplo la biblioteca de hilos de ZeroC ICE que 
se discutira en la siguiente seccion. 



o 



Aunque los semaforos y las colas de mensajes pueden presen- 
tar ciertas limitaciones que justifiquen el uso de mecanismos 
de un mayor nivel de abstraccion, los primeros pueden ser mas 
adecuados que estos ultimos dependiendo del problema a so- 
lucionar. Considere las ventajas y desventajas de cada herra- 
mienta antes de utilizarla. 



En el caso de los lenguajes de programacion con un soporte nativo 
de concurrencia, Ada es uno de los casos mas relevantes en el ambito 
comercial, ya que originalmente fue disenado 1 para construir sistemas 
de tiempo real criticos prestando especial importancia a la fiabilidad. 
En este contexto, Ada proporciona elementos especificos que facili- 
tan la implementacion de soluciones con necesidades de concurrencia, 
sincronizacion y tiempo real. 

En el caso de las bibliotecas externas, uno de sus principales ob- 
jetivos de diseno consiste en solventar las limitaciones previamente 
introducidas. Para ello, es posible incorporar nuevos mecanismos de 
sincronizacion de mas alto nivel, como por ejemplo los monitores, o 
incluso anadir mas capas software que permitan que el desarrollador 
se abstraiga de aspectos especificos de los mecanismos de mas bajo 
nivel, como por ejemplo los semaforos. 



4.2. Concurrencia en Ada 95 

Ada es un lenguaje de programacion orientado a objetos, fuerte- 
mente tipado, multi-proposito y con un gran soporte para la progra- 
macion concurrente. Ada fue disenado e implementado por el Depar- 
tamento de Defensa de los Estados Unidos. Su nombre se debe a Ada 
Lovelace, considerada como la primera programadora en la historia de 
la Informatica. 

Uno de los principales pilares de Ada reside en una filosofia basada 
en la reduccion de errores por parte de los programadores tanto como 
sea posible. Dicha filosofia se traslada directamente a las construccio- 
nes del propio lenguaje. Esta filosofia tiene como objetivo principal la 
creacion de programas altamente legibles que conduzcan a una maxi- 
mizacion de su mantenibilidad. 

Ada se utiliza particularmente en aplicaciones vinculadas con la 
seguridad y la fiabilidad, como por ejemplos las que se enumeran a 
continuacion: 



*Ada fue disenado por el Departamento de Defensa de EEUU. 
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■ Aplicaciones de defensa (e.g. DoD de EEUU). 

■ Aplicaciones de aeronautica (e.g. empresas como Boeing o Air- 
bus). 

■ Aplicaciones de gestion del trafico aereo (e.g. empresas como In- 
dira). 

■ Aplicaciones vinculadas a la industria aeroespacial (e.g. NASA). 

Resulta importante resaltar que en esta seccion se realizara una 
discusion de los elementos de soporte para la concurrencia y la sin- 

cronizacion ofrecidos por Ada 95, asi como las estructuras propias 
del lenguaje para las necesidades de tiempo real. Sin embargo, no se 
llevara a cabo un recorrido por los elementos basicos de este lenguaje 
de programacion. 

En otras palabras, en esta seccion se consideraran especialmen- 
te los elementos basicos ofrecidos por Ada 95 para la programacion 
concurrente y los sistemas de tiempo real. Para ello, la perspectiva 
abordada girara en torno a dos conceptos fundamentales: 

1. El uso de esquemas de programacion concurrente de alto ni- 
vel, como por ejemplo los objetos protegidos estudiados en la 
seccion 4.2.2. 

2. El uso practico de un lenguaje de programacion orientado al di- 
seno y desarrollo de sistemas concurrentes. 

Antes de pasar a discutir un elemento esencial de Ada 95, como es 
el concepto de tarea, el siguiente listado de codigo muestra una posible 
implementacion del clasico programa ;Hola Mundo! 



Listado 4.1: ;Hola Mundo! en Ada 95. 



with Text_I0; use Text_I0; 

2 

procedure HolaMundo is 
begin 

Put_Line ( "Hola Mundo!"); 
end HolaMundo; 



Para poder compilar y ejecutar los ejemplos implementados en Ada 
95 se hara uso de la herramienta gnatmake, la cual se puede instalar 
en sistemas GNU/Linux mediante el siguiente comando: 

$ sudo apt-get install gnat 




GNAT es un compilador basado en la infraestructura de gcc y 
utilizado para compilar programas escritos en Ada. 
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Una vez instalado GNAT, la compilacion y ejecucion de programas 
escritos en Ada es trivial. Por ejemplo, en el caso del ejemplo ;Hola 
Mundo! es necesario ejecutar la siguiente instruccion: 

$ gnatmake holamundo . adb 



4.2.1. Tareas y sincronizacion basic a 

En Ada 95, una tarea representa la unidad basica de programa- 
cion concurrente [3]. Desde un punto de vista conceptual, una tarea 
es similar a un proceso. El siguiente listado de codigo muestra la defi- 
nicion de una tarea sencilla. 



Listado 4.2: Definicion de tarea simple en Ada 95. 



1 — Especif icacion de la tarea T. 
task type T; 

3 

4 Cuerpo de la tarea T. 
task body T is 

— Declaraciones locales al cuerpo. 

— Orientado a objetos (Duration) . 
periodo : Duration := Duration ( 1 0 ) ; 

— Identif icador de tarea. 
id_tarea : Task_Id := Null_Task_Id; 

11 

12 begin 

13 -- Current Task es similar a getpidO . 

14 id_tarea := Current_Task; 

15 Bucle infinito. 

16 loop 

17 — Retraso de 'periodo' segundos . 

18 delay periodo; 

19 Impresion por salida estandar. 
Put (" Identif icador de tarea: "); 
Put_Line (Image (ID_T) ) ; 

22 end loop; 

23 

24 end T; 



Como se puede apreciar, la tarea esta compuesta por dos elementos 
distintos: 

1 . La especificacion (declaracion) de la tarea T. 

2. El propio cuerpo (definicion) de la tarea T. 
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El lanzamiento de tareas es sencillo ya que estas se activan de 
manera automatica cuando la ejecucion llega al procedimiento (proce- 
dure) en el que esten declaradas. Asi, el procedimiento espera la fina- 
lizacion de dichas tareas. En el siguiente listado de codigo se muestra 
un ejemplo. 

Es importante resaltar que Tareal y Tarea2 se ejecutaran concu- 
rrentemente despues de la sentencia begin (linea fijfj) , del mismo modo 
que ocurre cuando se lanzan diversos procesos haciendo uso de las 
primitivas que proporciona, por ejemplo, el estandar POSIX. 



Listado 4.3: Activacion de tareas en Ada 95. 



1 — Inclusion de paquetes de E/S e 

2 — identif icacion de tareas. 

with Ada . Text_I0; use Ada . Text_I0; 
with Ada . Task_Identif ication; 
use Ada . Task_Identif ication; 

6 

procedure Prueba_Tareas is 

— Inclusion del anterior listado de codigo... 

9 

10 — Variables de tipo T. 

11 Tareal :T; 

12 Tarea2:T; 
13 

begin 

15 — No se hace nada, pero las tareas se activan. 

16 null; 

17 end Prueba_Tareas; 



La representacion y el lanzamiento de tareas se completa con su 
finalizacion. Asi, en Ada 95, una tarea finalizara si se satisface alguna 
de las siguientes situaciones [3]: 

1. La ejecucion de la tarea se completa, ya sea de manera normal o 
debido a la generacion de alguna excepcion. 

2. La tarea ejecuta una alternativa de finalizacion mediante una ins- 
truccion select, como se discutira con posterioridad. 

3. La tarea es abortada. 

La sincronizacion basica entre tareas en Ada 95 se puede reali- 
zar mediante la definicion de entries (entradas). Este mecanismo de 
interaccion proporcionado por Ada 95 sirve como mecanismo de co- 
municacion y de sincronizacion entre tareas. Desde un punto de vista 
conceptual, un entry se puede entender como una llamada a un pro- 
cedimiento remoto de manera que 

1 . la tarea que invoca suministra los datos a la tarea receptora, 

2. la tarea receptora ejecuta el entry, 



3. la tarea que invoca recibe los datos resultantes de la invocacion. 
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De este modo, un entry se define en base a un identificador y una 
serie de parametros que pueden ser de entrada, de salida o de entra- 
da/salida. Esta ultima opcion, a efectos practicos, representa un paso 
de parametros por referencia. 

En el contexto de la sincronizacion mediante entries, es importante 
hacer especial hincapie en que el entry lo ejecuta la tarea invocada, 
mientras que la que invoca se queda bloqueada hasta que la ejecucion 
del entry se completa. Este esquema de sincronizacion, ya estudia- 
do en la seccion 2.3.5, se denomina sincronizacion mediante Rendez- 
vous. 

Antes de estudiar como se puede modelar un problema clasico de 
sincronizacion mediante el uso de entries, es importante considerar 
lo que ocurre si, en un momento determinado, una tarea no puede 
atender una invocacion sobre un entry. En este caso particular, la 
tarea que invoca se bloquea en una cola FIFO vinculada al propio 
entry, del mismo modo que suele plantearse en las implementacion de 
los semaforos y la primitiva wait. 

Modelando el problema del buffer limitado 

El problema del buffer limitado, tambien conocido como problema 
del productor/consumidor, plantea la problematica del acceso concu- 
rrente al mismo por parte de una serie de productores y consumidores 
de informacion. En la seccion 1.2.1 se describe esta problematica con 
mayor profundidad, mientras que la seccion 2.3. 1 discute una posible 
implementacion que hace uso de semaforos. 

En esta seccion, tanto el propio buffer en el que se almacenaran los 
datos como los procesos productor y consumidor se modelaran median- 
te tareas. Por otra parte, la gestion del acceso concurrente al buffer, 
asi como la insercion y extraccion de datos, se realizara mediante dos 
entries, denominados respectivamente escribir y leer. 

Debido a la necesidad de proporcionar distintos servicios, Ada 95 
proporciona la instruccion select con el objetivo de que una tarea 
servidora pueda atender multiples entries. Este esquema proporciona 
un mayor nivel de abstraccion desde el punto de vista de la tarea 
que solicita o invoca un servicio, ya que el propio entorno de ejecucion 
garantiza que dos entries, gestionadas por una sentencia select, nunca 
se ejecutaran de manera simultanea. 

El siguiente listado de codigo muestra una posible implementacion 
de la tarea Buffer para llevar a cabo la gestion de un unico elemento 
de informacion. 

Como se puede apreciar, el acceso al contenido del buffer se realiza 
mediante Escribir y Leer. Note como el parametro de este ultimo entry 
es de salida, ya que Leer es la operacion de extraccion de datos. 
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Listado 4.4: Implementacion de la tarea Buffer en Ada 95. 



1 — Buffer de un unico elemento. 

2 task Buffer is 

entry Escribir (Dato: Integer); 
entry Leer (Dato: out Integer); 
end Buffer; 

6 

7 task body Buffer is 
Temp: Integer; 
begin 

10 loop 

11 select 

12 — Almacenamiento del valor entero . 
accept Escribir (Dato: Integer) do 

14 Temp := Dato; 

15 end Escribir; 

16 or 

17 Recuperacion del valor entero. 
accept Leer (Dato: out Integer) do 

Dato := Temp; 

20 end Leer; 

21 end select; 
end loop; 

23 end Buffer; 



A continuacion se muestra una posible implementacion, a modo de 
ejemplo, de la tarea Consumidor. 



Listado 4.5: Implementacion de la tarea Consumidor en Ada 95. 



task Consumidor; 

2 

3 task body Consumidor is 
Dato : Integer; 

5 

begin 
loop 

8 — Lectura en 'Dato' . 

Buffer . Leer (Dato) ; 

Put_Line (" [Consumidor] Dato obtenido . . . " ) ; 

11 Put_Line (Dato' img) ; 

12 delay 1.0; 

13 end loop; 

14 

end Consumer; 



El buffer de la version anterior solo permitia gestionar un elemento 
que fuera accedido de manera concurrente por distintos consumidores 
o productores. Para manejar realmente un buffer limitado, es decir, 
un buffer con una capacidad maxima de N elementos, es necesario 
modificar la tarea Buffer anadiendo un array de elementos, tal y como 
muestra el siguiente listado de codigo. 

Como se puede apreciar, el buffer incluye logica adicional para con- 
trolar que no se puedan insertar nuevos elementos si el buffer esta 
lleno o, por el contrario, que no se puedan extraer elementos si el bu- 
ffer esta vacio. Estas dos situaciones se controlan por medio de las 
denominadas barreras o guardas, utilizando para ello la palabra re- 
servada when en Ada 95. Si la condicion asociada a la barrera no se 
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cumple, entonces la tarea que invoca la funcion se quedara bloqueada 
hasta que se cumpla, es decir, hasta que la barrera se levante. 



Listado 4.6: Implementation de la tarea Buffer (limitado) en Ada 95. 



1 — Buffer de un MaxTamanyo elementos . 
task Buffer is 

entry Escribir (Elem: TElemento) ; 

entry Leer (Elem: out TElemento) ; 
end Buffer; 

6 

task body Buffer is 

MaxTamanyo: constant := 10; — Buffer limitado. 

Datos : array ( 1 . .MaxTamanyo) of TElemento; 

I, J: Integer range 1 .. MaxTamanyo := 1; 

Tamanyo : Integer range 0 .. MaxTamanyo := 0; 
begin 

loop 

14 select 

15 when Tamanyo < MaxTamanyo => 

16 accept Escribir (Elem: TElemento) do 

17 Datos (i) := Elem; Guarda el elemento. 

18 end Escribir; 

19 I := I mod MaxTamanyo + 1; 

20 Tamanyo := Tamanyo + 1; 

21 or 

22 when Tamanyo > 0 => 

accept Leer (Elem: out TElemento) do 

Elem := Datos (J) ; — Devuelve el elemento. 

25 end Leer; 

26 J := J mod MaxTamanyo + 1; 

27 Tamanyo := Tamanyo - 1; 
end select; 

29 end loop; 

30 end Buffer; 



En este contexto, estas construcciones son mas naturales que el 
uso de semaforos contadores o buzones de mensajes con un determi- 
nado tamano maximo. 

De nuevo, el control concurrente sobre las operaciones leer y escri- 
bir se gestiona mediante el uso de entries. 
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4.2.2. Los objetos protegidos 

Hasta ahora se ha estudiado como las tareas permiten encapsular 
datos sin la necesidad de un mecanismo de exclusion mutua explicito. 
Por ejemplo, en el caso del buffer limitado de la anterior seccion, no 
es necesario utilizar ningun tipo de mecanismo de exclusion mutua ya 
que su contenido nunca sera accedido de manera concurrente. Este 
hecho se debe a la propia naturaleza de los entries. 

Sin embargo, utilizar tareas para servir datos puede introducir una 
sobrecarga en la aplicacion. Ademas, las tareas no representan la for- 
ma mas natural de encapsular datos y, de manera simultanea, ofrecer 
una funcionalidad a potenciales clientes. 




Las regiones criticas condicionales representan un mecanismo 
de sincronizacion mas natural y sencillo de entender e imple- 
mentar. 



En Ada, un objeto protegido es un tipo de modulo protegido que 

encapsula una estructura de datos y exporta subprogramas o funcio- 
nes [3]. Estos subprogramas operan sobre la estructura de datos bajo 
una exclusion mutua automatica. Del mismo modo que ocurre con las 
tareas, en Ada es posible definir barreras o guardas en las propias 
entradas, que deben evaluarse a verdadero antes de que a una tarea 
se le permita entrar. Este planteamiento se basa en la definicion de 
regiones criticas condicionales. 

El siguiente listado de codigo muestra un ejemplo sencillo de tipo 
protegido para un entero compartido [3] . 



Listado 4.7: Ejemplo simple de tipo protegido. 



1 Tipo protegido para un entero compartido. 

protected type EnteroCompartido (Valor Inicial : Integer) is 
function Leer return Integer; 

procedure Escribir (NuevoValor : Integer) ; 
procedure Incrementar (Incremento : Integer); 

6 

private 

Dato : Integer := Valor Inicial ; 

9 

end EnteroCompartido; 

11 

12 V : EnteroCompartido ( 7 ) ; 



La declaracion de V en la linea (TF) declara una instancia de dicho 
tipo protegido y le asigna el valor inicial al dato que este encapsula. 
Este valor solo puede ser accedido mediante Leer, Escribir e Incremen- 
tar. En este contexto, es importante destacar las diferencias existentes 
al usar procedimientos o funciones protegidas: 
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Las llamadas a entradas protegidas se usan para Implementar 
la sincronizacion de condicion. 



■ Un procedimiento protegido, como Escribir o Incrementar, pro- 
porciona un acceso mutuamente excluyente tanto de lectura co- 
mo de escritura a la estructura de datos encapsulada por el tipo 
protegido. En otras palabras, las llamadas a dichos procedimien- 
tos se ejecutaran en exclusion mutua. 

■ Una funcion protegida, como Leer, proporciona acceso concu- 
rrente de solo lectura a la estructura de datos encapsulada. En 
otras palabras, es posible que multiples tareas ejecuten Leer de 
manera concurrente. No obstante, las llamadas a funciones pro- 
tegidas son mutuamente excluyentes con las llamadas a procedi- 
mientos protegidos. 

Finalmente, una entrada protegida es similar a un procedimiento 
protegido. La diferencia reside en que la entrada esta asociada a una 
barrera integrada en el propio objeto protegido. Como se comento an- 
teriormente, si la evaluacion de dicha barrera obtiene un valor logico 
falso, entonces la tarea que invoca dicha entrada se quedara suspen- 
dida hasta que la barrera se evalue a uerdadero y, adicionalmente, no 
existan otras tareas activas dentro del objeto protegido. 



Las barreras se evaluan siempre que una nueva tarea evalua la 
barrera y esta haga referenda a una variable que podria haber 
cambiado desde que la barrera fue evaluada por ultima vez. Asi 
mismo, las barreras tambien se evaluan si una tarea abandona 
un procedimiento o entry y existen tareas bloqueadas en barre- 
ras asociadas a una variable que podria haber cambiado desde 
la ultima evaluacion. 



A continuacion se discutira un problema de sincronizacion clasi- 
co, ya discutido en la seccion 2.3.3, implementado haciendo uso de 
objetos protegidos. 




Modelando el problema de los filosofos comensales 

En esta seccion se discute una posible implementacion del proble- 
ma de los filosofos comensales utilizando Ada 95 y objetos protegidos 2 . 

En la seccion 2.3.3, los palillos se definian como recursos indivisi- 
bles y se modelaban mediante semaforos binarios. De este modo, un 

2 C6digo fuente adaptado a partir de la implementacion de 
http://es.wikibooks.org/wiki/Programaci%C3%B3n_en_Ada/Tareas/Ejemplos 
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palillo cuyo semaforo tuviera un valor de 1 podria ser utilizado por un 
filosofo, simulando su obtencion a traves de un decremento (primitiva 
wait) del semaforo y bloqueando al filosofo adyacente en caso de que 
este ultimo quisiera cogerlo. 

En esta solucion, el palillo se modela mediante un objeto prote- 
gido. Para ello, el siguiente listado de codigo define el tipo protegido 
Cubierto. 



Listado 4.8: Declaracion del objeto protegido Cubierto. 



1 — Codigo adaptado de . . . 

2 — http://es.wikibooks.org/wiki/Programaci 

3 package Cubiertos is 
4 

type Cubierto is limited private; 

6 

procedure Coger(C: in out Cubierto); 
procedure Soltar(C: in out Cubierto); 

9 

private 

11 

12 type Status is (LIBRE, OCUPADO); 

13 

protected type Cubierto (Estado_Cubierto : Status := LIBRE) is 

15 entry Coger; 

16 entry Soltar; 

17 

18 private 

19 Estado: Status := Estado_Cubierto; 
end Cubierto; 

21 

22 end Cubiertos; 



Como se puede apreciar, dicho tipo protegido mantiene el estado 
del cubierto como un elemento de tipo Status (linea (~iT)), que puede ser 
LIBRE u OCUPADO, como un dato privado, mientras que ofrece dos 
entries protegidos: Coger y Soltar (lineas [i6-i7p . Note como el estado 
del tipo Cubierto se inicializa a LIBRE (linea (jsj). 

Por otra parte, el objeto protegido Cubierto esta integrado dentro 
del paquete Cubiertos, cuya funcionalidad esta compuesta por los pro- 
cedimientos Coger y Soltar (lineas (TjFj) . Dichos procedimientos actuan 
sobre los cubiertos de manera individual (observe el parametro de en- 
trada/salida C, de tipo Cubierto en ambos). 

A continuacion se muestra la implementacion de los procedimien- 
tos y entries declarados en el anterior listado. Note como los proce- 
dimientos simplemente delegan en los entries asociados la gestion de 
la exclusion mutua. Por ejemplo, el procedimiento publico Coger del 
paquete cubiertos invoca el entry Coger del cubierto pasado como pa- 
rametro a dicho procedimiento (lineas ( 6-9) ) . 
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Listado 4.9: Implementacion del objeto protegido Cubierto. 



1 — Codigo adaptado de . . . 

2 — http://es.wikibooks.org/wiki/Programaci 
package body Cubiertos is 

procedure Coger (C: in out Cubierto) is 
begin 

7 C. Coger; 

end Coger; 

9 

procedure Soltar (C: in out Cubierto) is 

11 begin 

12 C. Soltar; 

13 end Soltar; 
14 

protected body Cubierto is 

16 

entry Coger when Estado = LIBRE is 
18 begin 

Estado := OCUPADO; 
20 end Coger; 

21 

22 

entry Soltar when Estado = OCUPADO is 

24 begin 

25 Estado := LIBRE; 
end Soltar; 

27 

end Cubierto; 

29 

30 end Cubiertos; 



La vlda de un filosofo 



Recuerde que, en el proble- 
ma clasico de los fllosofos co- 
mensales, estos vlven un ci- 
clo continuo compuesta de 
las actlvldades de comer y 
pensar. 



El aspecto mas destacable de esta implementacion es el uso de sen- 
das barreras en los entries Coger y Soltar para controlar si un cubierto 
esta libre u ocupado antes de cogerlo o soltarlo, respectivamente. 

En este punto, el objeto protegido Cubierto ya gestiona el acceso 
concurrente y exclusivo a los distintos cubiertos que se vayan a ins- 
tanciar. Este numero coincide con el numero de fllosofos que se sen- 
taran a la mesa. Por lo tanto, el siguiente paso consiste en modelar 
la tarea Filosofo y plantear el codigo necesario para llevar a cabo la 
simulacion del problema. 

El siguiente listado de codigo muestra el modelado de un filosofo. La 
parte mas importante esta representada por el procedimiento Pensar 
(lineas [li-iafl, en el que el filosofo intenta obtener los palillos que se 
encuentran a su izquierda y a su derecha, respectivamente, antes de 
comer. El procedimiento Pensar (lineas [20-24] ) simplemente realiza una 
espera de 3 segundos. 
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Listado 4. 10: Tarea filosofo en Ada. 



1 — Codigo adaptado de . . . 

2 — http ://es. wikibooks . org/wiki/Programacion_en_Ada/Tareas/E jemplos 
type PCubierto is access Cubierto; 

4 

5 task type TFilosof o (Id: Character; 

Cubierto_I zquierda : PCubierto; Cubierto_Derecha : 
PCubierto) ; 

7 

8 task body TFilosofo is 

9 

10 procedure Comer is 

11 begin 

12 Intenta obtener el cubierto izquierdo y el derecho. 

13 Coger (Cubierto_Izquierda . all) ; 

14 Coger (Cubierto_Derecha . all ) ; 

15 Put (Id & "c "); delay 1.0; 

16 Soltar (Cubierto_Derecha . all) ; 

17 Soltar (Cubierto_I zquierda . all) ; 

18 end Comer; 
19 

Procedure Pensar is 

21 begin 

22 Put (Id & "p ") ; 

23 delay 3.0; 

24 end Pensar; 

25 

26 begin 

loop 

28 Comer; Pensar; 

end loop; 

30 end TFilosofo; 



Finalmente, el siguiente listado muestra la logica necesaria para 
simular el problema de los filosofos comensales. Basicamente, lleva a 
cabo la instanciacion de los cubiertos como objetos protegidos (lineas 
( 25-27 )) y la instanciacion de los filosofos (lineas [ 30-35 )). 



Listado 4.11: Simulacion de los filosofos. 



1 — Codigo adaptado de . . . 

2 — http://es.wikibooks.org/wiki/Programaci 

3 with Ada.Text_I0; use Ada.Text_I0; 

with Ada . Integer_Text_I0; use Ada . Integer_Text_I0; 
with Cubiertos; use Cubiertos; 

6 

procedure Problema_Filosof os is 

8 

9 — Aqui el codigo del listado anterior. . . 
10 

11 N_Cubiertos : Positive; 
12 

13 begin 

14 

Put("Numero de filosofos: "); Get (N_Cubiertos ) ; New_line; 

16 

17 declare 

type PTFilosofo is access TFilosofo; 

19 P: PTFilosofo; 

20 C: Character := 'A'; 

Cuberteria: array ( 1 . . N_Cubiertos ) of PCubierto; 
22 begin 
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23 -- Instanciacion de los cubiertos . 

for i in 1 . . N_Cubiertos loop 

25 Cuberteria (i) := new Cubierto; 

26 end loop; 

27 

28 — Instanciacion de los filosofos (A, B, C, D, etc) . 

for i in 1 . . N_Cubiertos-l loop 
P := new TFilosofo (C, Cuberteria ( i ) , Cuberteria ( i+1 )) ; 
C := Character' Succ (C) ; — Sucesor para generar el siguiente 
ID . 
end loop; 

El ultimo filosofo comparte palillo con el primero. 
P := new TFilosofo (C, Cuberteria ( 1 ) , Cuberteria (N_Cubiertos ) ) 

35 end; 



36 end Problema Filosofos ; 



Si desea llevar a cabo una simulacion para comprobar que, efecti- 
vamente, el acceso concurrente a los palillos es correcto, recuerde que 
ha de ejecutar los siguientes comandos: 

$ gnatmake problemaf ilosof os . adb 
$ . /problema_f ilosof os 



Si la compilacion y la ejecucion fueron correctas, entonces el resul- 
tado obtenido de la simulacion deberia ser similar al siguiente. 



Introduzca el numero 


de 


cubiertos/f ilosofos : 


5 
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donde la primera letra de cada palabra representa el identificador del 
filosofo (por ejemplo A) y la segunda representa el estado (pensando 
o comiendo). Note como el resultado de la simulacion no muestra dos 
filosofos adyacentes (por ejemplo A y B o B y C) comiendo de manera 
simultanea. 



4.3. El concepto de monitor 

Con el objetivo principal de mejorar y flexibilizar los mecanismos 
de sincronizacion basicos estudiados, uso de semaforos y de colas de 
mensajes, han surgido herramientas de sincronizacion de mas alto 
nivel, como los monitores. En esta seccion se discutira el caso concreto 
de los monitores, introducidos previamente en la seccion 1.2.3. 

Desde un punto de vista general, un monitor se puede definir como 
un tipo abstracto de datos con un conjunto de operaciones, espe- 
cificadas por el programador, que operan en exclusion mutua sobre 
el propio monitor. En otras palabras, se persigue que el acceso a los 
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elementos del tipo abstracto de datos sea correcto desde el punto de 
vista de la concurrencia. 

Segun [3], los monitores surgen como un refinamiento de las sec- 
ciones criticas condicionales, es decir, como una evolucion de las mis- 
mas pero con la idea de solventar algunas de las limitaciones discu- 
tidas en la seccion 4.1. En concrete la dispersion de las secciones 
criticas en un programa con relativa complejidad destruye el concepto 
de programacion estructurada, obteniendo asi un codigo cuya legibili- 
dad y mantenimiento se ven afectados. 

En la seccion 2.3.1 se estudio el uso de semaforos para modelar 
una solucion al problema clasico del buffer limitado. En esencia, 
dicha solucion contemplaba el uso de dos semaforos de tipo contador: 
i) empty, para controlar el mimero de huecos vacios, y ii) full, para 
controlar el mimero de huecos llenos. Ademas, se hacia uso de un 
semaforo binario, denominado mutex, para controlar el acceso a la 
seccion critica. 

Este planteamiento es poco natural en el sentido de que no se trata 
al buffer limitado como una estructura que gestiona el acceso con- 
currente por parte de otros procesos o hilos. Por el contrario, dicho 
acceso se controla desde una perspectiva externa mediante el uso de 
diversos semaforos. 




El uso de monitores permite encapsular el estado o variables, 
que seran accedidas en exclusion mutua, del propio monitor. 



En este contexto, el monitor permite modelar el buffer de una ma- 
nera mas natural mediante un modulo independiente de manera que 
las llamadas concurrentes para insertar o extraer elementos del bu- 
ffer se ejecutan en exclusion mutua. En otras palabras, el monitor 
es, por definicion, el responsable de ejecutarlas secuencialmente de 
manera correcta. La figura 4. 1 muestra la sintaxis de un monitor. En 
la siguiente seccion se discutira como se puede utilizar un monitor 
haciendo uso de las facilidades que proporciona el estandar POSIX. 

Sin embargo, y aunque el monitor proporciona exclusion mutua 
en sus operaciones, existe la necesidad de la sincronizacion dentro 
del mismo. Una posible opcion para abordar esta problematica podria 
consistir en hacer uso de semaforos. No obstante, las implementacio- 
nes suelen incluir primitivas que sean mas sencillas aun que los pro- 
pios semaforos y que se suelen denominar variables de condicion. 

Las variables de condicion, sin embargo, se manejan con primiti- 
vas muy parecidas a las de los semaforos, por lo que normalmente 
se denominan wait y signal. Asi, cuando un proceso o hilo invoca 
wait sobre una variable de condicion, entonces se quedara bloqueado 
hasta que otro proceso o hilo invoque signal. Note que wait siempre 
bloqueara al proceso o hilo que lo invoque, lo cual supone una dife- 
rencia importante con respecto a su uso en semaforos. 
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monitor nombre_monitor { 

/* Declaracion de variables compartidas */ 
procedure pi (...) { ... } 
procedure p2 (...) { ... } 

procedure pn (...) { ... } 
inicializacion (...) { 



Figura 4.1: Sintaxls general de un monitor. 



Al igual que ocurre con los semaforos, una variable de condicion 
tiene asociada alguna estructura de datos que permite almacenar in- 
formacion sobre los procesos o hilos bloqueados. Tipicamente, esta 
estructura de datos esta representada por una cola FIFO (Jirst-injirst- 
out). 

Tenga en cuenta que la liberacion de un proceso bloqueado en una 
variable de condicion posibilita que otro proceso pueda acceder a la 
seccion critica. En este contexto, la primitiva signal es la que posibili- 
ta este tipo de sincronizacion. Si no existe ningun proceso bloqueado 
en una variable de condicion, entonces la ejecucion de signal sobre la 
misma no tiene ningun efecto. Esta propiedad tambien representa una 
diferencia importante con respecto a la misma primitiva en un semafo- 
ro, ya que en este ultimo caso si que tiene un efecto final (incremento 
del semaforo). 



o 



La construction del monitor garantiza que, en cualquier mo- 
menta de tiempo, solo haya un proceso activo en el monitor. 
Sin embargo, puede haber mas procesos o hilos suspendidos 
en el monitor. 



Antes de pasar a la siguiente seccion, en la que se estudiara el caso 
particular de los monitores en POSIX (mediante el uso de mutexes y 
variables de condicion), es importante destacar que las variables de 
condiciones padecen algunas de las desventajas asociadas al uso de 
semaforos, introducidas en la seccion 4.1 del presente capitulo. Por 
ejemplo, el uso de las primitivas wait y signal puede propiciar errores 
cometidos por parte del programador y que, en ocasiones, implica que 
el proceso de depuracion para localizarlos sea tedioso. 



4.3.1. Monitores en POSIX 

Para modelar el comportamiento de un monitor utilizando las pri- 
mitivas que ofrece el estandar POSIX y, en concrete la biblioteca Pth- 
reads, es necesario utilizar algun mecanismo para garantizar la ex- 
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elusion mutua en las operaciones del monitor y proporcionar la sin- 
cronizacion necesario. En este contexto, POSIX Pthreads ofrece tanto 
mutexes como variables de condicion para llevar a cabo dicho mo- 
delado. 

Con el objetivo de ejemplificar el uso de monitores mediante estos 
dos elementos definidos en POSIX, en esta seccion se retoma el ejem- 
plo del buffer limitado previamente discutido en la seccion 2.3. 1, en la 
que se hizo uso de semaforos para controlar el acceso al buffer. Para 
ello, se asumiran las siguientes suposiciones: 

1 . El buffer estara implementado en base a la definicion de monitor. 

2. Los productores y consumidores de informacion, es decir, las 
entidades que interactuan con el buffer, estaran implementados 
mediante hilos a traves de la biblioteca Pthread. 

Con el objetivo de encapsular el estado del buffer, siguiendo la filo- 
sofia planteada por el concepto de monitor, se ha definido la clase Bu- 
ffer mediante el lenguaje de programacion C++, tal y como se muestra 
en el siguiente listado de codigo. 



Listado 4.12: Clase Buffer. 



#ifndef BUFFER_H 

#define BUFFER_H 

3 

#include <pthread.h> 

5 

#define MAX_T AMAN Y O 5 

7 

class Buffer { 
public : 

Buffer ( ) ; 

11 -Buffer ( ) ; 

12 void anyadir (int dato) ; 

13 int extraer (); 
14 

15 private: 

16 int _n_datos; 

17 int _primero, _ultimo; 

18 int _datos [MAX_TAMANYO] ; 
19 

20 pthread_mutex_t _mutex; 

21 pthread_cond_t _buf f er_no_lleno; 

22 pthread_cond_t _buf f er_no_vacio; 
1 ; 

24 

25 #endif 



La funcionalidad relevante de la clase Buffer esta especificada en 
las lineas [ 12-13) , en las que se declaran las funciones anyadir y extraer. 
Respecto al estado del propio buffer, cabe destacar dos grupos de 
elementos: 

■ Las variables de clase relacionadas con el numero de elementos 
en el buffer y los apuntadores al primer y ultimo elemento (lineas 
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[ 16-18 )), respectivamente. La figura 4.2 muestra de manera grafica 
dichos apuntadores. 

■ Las variables de clase que realmente modelan el comportamiento 
del buffer, es decir, el mutex de tipo pthread_mutex_t para ga- 
rantizar el acceso excluyente sobre el buffer y las variables de 
condicion para llevar a cabo la sincronizacion. 

Estas variables de condicion permiten modelar, a su vez, dos si- 
tuaciones esenciales a la hora de interactuar con el buffer: 

1. La imposibilidad de anadir elementos cuando el buffer esta lleno. 
Esta situacion se contempla mediante la variable _buffer_no_lleno 
del tipo pthread_cond. 

1. La imposibilidad de extraer elementos cuando el buffer esta vacio. 
Esta situacion se contempla mediante la variable _buffer_no_vacio 
del tipo pthread_cond. 

El constructor y el destructor de la clase Buffer permiten inicia- 
lizar el estado de la misma, incluyendo los elementos propios de la 
biblioteca Pthread, y liberar recursos, respectivamente, tal y como se 
muestra en el siguiente listado de codigo. 

La funcion anyadir permite insertar un nuevo elemento en el bu- 
ffer de tamafio limitado. Con el objetivo de garantizar que dicha fun- 
cion se ejecute en exclusion mutua, el mutex se adquiere justo en la 
primera instruccion (linea (7)) y se libera en la ultima (linea [go]), como 
se aprecia en el siguiente listado. 



Listado 4.13: Clase Buffer. Constructor y destructor. 



finclude "buffer.h" 
#include <assert.h> 

3 

Buffer: :Buffer () : 

5 _n_datos(0), _primero(0), _ultimo(0) 

6 { 

pthread_mutex_init (&_mutex, NULL) ; 
pthread_cond_init (&_buf fer_no_lleno, NULL); 
pthread_cond_init (&_buf fer_no_vacio, NULL); 

10 } 

11 

12 Buffer: :~Buffer () 

13 { 

pthread_mutex_destroy (S_mutex) ; 

15 pthread_cond_destroy (&_buf fer_no_lleno) ; 

16 pthread_cond_destroy (&_buf fer_no_vacio) ; 

17 } 



A continuacion, y antes de insertar cualquier elemento en el bu- 
ffer, es necesario comprobar que este no este lleno. Para ello, se usa la 
condicion del bucle while (linea (Tj). Si es asi, es decir, si el buffer ha 
alcanzado su limite, entonces se ejecuta un wait sobre la variable de 
condicion _buffer_no_lleno, provocando las dos siguientes consecuen- 
cias: 
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Tamano del buffer 
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primero 



ultimo 



Figura 4.2: Esquema grafico del buffer limitado modelado mediante un monitor. 

1. El hilo que ejecuta anyadir se queda bloqueado y se encola en la 
cola asociada a dicha variable de condicion. 

2. El mutex se libera, con el objetivo de que otro hilo, productor o 
consumidor, pueda ejecutar anyadir o extraer, respectivamente. 
Note como el segundo parametro de pthread_cond_wait es preci- 
samente el mutex del propio buffer. Asi, con un monitor es posible 
suspender varios hilos dentro de la seccion critica. pero solo es 
posible que uno se encuentre activo en un instante de tiempo. 



Listado 4.14: Clase Buffer. Insercion de elementos. 



i 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 



void 

Buffer: : anyadir 
(int dato) 
{ 

/+ Adquisicion el mutex para exclusion mutua */ 
pthread_mutex_lock (&_mutex) ; 

/* Para controlar que no haya desbordamiento */ 
while (_n_datos == MAX_TAMAN YO ) 

/* Sincronizacion */ 

pthread_cond_wait (&_buf f er_no_lleno, &_mutex) ; 

/+ Actualizacion del estado del buffer */ 
_datos [_ultimo % MAX_TAMANYO] = dato; 
++_ultimo; 
++_n_datos ; 

/* Sincronizacion */ 

pthread_cond_signal ( &_buf f er_no_vacio) ; 
pthread_mutex_unlock (&_mutex) ; 



La actualizacion del estado del buffer mediante la funcion anya- 
dir consiste en almacenar el dato en el buffer (linea [U]), actualizar el 
apuntador para el siguiente elemento a insertar (linea (TTfl e incremen- 
tar el numero de elementos del buffer (linea fiF)). 



4.3. El concepto de monitor 
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Finalmente, es necesario ejecutar signed sobre la variable de con- 
dicion _buffer_no_vacio (linea [is] ) para desbloquear a algun hilo con- 
sumidor bloqueado, si lo hubiera, en dicha variable. Mas adelante se 
comprobara que un hilo consumidor se bloqueara cuando no haya 
ningun elemento que extraer del buffer. La ultima instruccion de an- 
yadir esta asociada a la liberacion del mutex (linea fio~] ) . 

El siguiente listado de codigo muestra la otra funcion relevante del 
buffer: extraer. Note como el esquema planteado es exactamente igual 
al de anyadir, con las siguientes salvedades: 

1. Un hilo se suspendera cuando no haya elementos o datos en 
el buffer (lineas [ 9-nj ) a traves de la variable de condicion _bu- 
ffer_no_vacio. 

2. La actualizacion de datos implica incrementar el apuntador al 
primer elemento a extraer y decrementar el numero total de datos 
(lineas [ is-i6 ]). 

3. La ejecucion de signal se realiza sobre _buffer_no_lleno, con el 
objetivo de desbloquear a un potencial productor de informacion. 

4. El valor extraido se devuelve despues de liberar el mutex. De otro 
modo, este no podria ser adquirido por otro hilo que intente ac- 
ceder al buffer con posterioridad. 



Listado 4.15: Clase Buffer. Extraccion de elementos. 



int 

2 Buf fer :: extraer () 

3 { 

4 int dato; 

5 

6 /* Adquisicion el mutex para exclusion mutua */ 

pthread_mutex_lock (&_mutex) ; 
8 /* No se puede extraer si no hay nada */ 
> while (_n_datos == 0) 
10 /* Sincronizacion */ 

pthread_cond_wait (&_buf f er_no_vacio, &_mutex) ; 

12 

13 /* Actualizacion del estado del buffer */ 

14 dato = _datos [_primero % MAX_TAMANYO] ; 

15 ++_primero; 
— _n_datos ; 

17 

18 /* Sincronizacion */ 

pthread_cond_signal ( &_buf f er_no_lleno ) ; 

20 

21 pthread_mutex_unlock ( &_mutex) ; 
22 

23 return dato; 

24 } 



En este punto, con el monitor ya implementado, el siguiente paso 
es crear un sencillo programa en el que una serie de hilos produc- 
tores y consumidores, implementados mediante la biblioteca Pthread, 
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interactuen con el monitor (buffer). El siguiente listado muestra la de- 
claracion de las funciones asociadas a dichos hilos y la creacion de los 
mismos. 

Note como la primitiva pthread_create se utiliza para asociar co- 
digo a los hilos productores y consumidor, mediante las funciones pro- 
ductorjunc (linea [21] ) y consumidor June (linea [23]), respectivamente. 
El propio puntero al buffer se pasa como parametro en ambos casos 
para que los hilos puedan interactuar con el. Cabe destacar igual- 
mente el uso de la primitiva pthreadjoin (linea [27] ) con el objetivo de 
esperar a los hilos creados anteriormente. 



Listado 4. 16: Creacion de hilos mediante Pthread. 



5 include; <iostream> 
#include <stdlib.h> 
#include <sys/types . h> 
5 include <unistd.h> 
#include "buffer.h" 

6 

#define NUM_HIL0S 8 

8 

static void *productor_f unc (void *arg) ; 
static void *consumidor_f unc (void *arg) ; 

11 

12 int main (int argc, char *argv[]) { 

13 Buffer *buffer = new Buffer; 

14 pthread_t tids [NUM_HIL0S] ; 

15 int i; 

16 srand ( (int ) getpid ( ) ) ; 
17 

18 /* Creacion de hilos */ 

for (i = 0; i < NUM_HIL0S; i++) 
20 if ( (i % 2) == 0) 

pthread_create ( &tids [ i ] , NULL, productor_f unc, buffer); 
22 else 

pthread_create ( Stids [ i ] , NULL, consumidor_f unc, buffer); 

24 

25 /* Esperando a los hilos */ 

26 for (i = 0; i < NUM_HIL0S; i++) 

27 pthreadjoin (tids [i] , NULL); 
28 

29 delete buffer; 
30 

31 return EXIT_SUCCESS ; 

32 } 



Finalmente, el siguiente listado muestra la implementacion de los 
hilos productor y consumidor, respectivamente, mediante sendas fun- 
ciones. En ellas, estos hilos interactuan con el buffer insertar o extra- 
yendo elementos de manera aleatoria y considerando una breve espera 
entre operacion y operacion. 



4.4. Consideraciones finales 
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Listado 4.17: Codigo fuente de los hilos productor y consumidor. 



static void *productor_f unc (void *arg) { 
2 Buffer *buffer = (Buffer *)arg; 
int i = 0, valor; 

4 

while (i < 10) { 

sleep (rand ( ) % 3 ) ; 
valor = rand() % 10; 
buf f er->anyadir (valor) ; 

std::cout << "Productor : \t" << valor << std::endl; 
10 + + i; 

) 

12 return (void *)true; 

13 } 
14 

15 static void *consumidor_f unc (void *arg) { 

16 Buffer ^buffer = (Buffer *)arg; 

17 int i = 0, valor; 

18 

19 while (i < 10) { 

20 sleep(rand() % 5); 

21 valor = buf f er->extraer ( ) ; 

std::cout << "Consumidor : \t" << valor << std::endl; 

23 ++i; 

24 } 

25 return (void *)true; 

26 } 



4.4. Consideraciones finales 

Como ya se introdujo al principio del presente capitulo, concreta- 
mente en la seccion 4.1, algunas de las limitaciones asociadas a los 
mecanismos de sincronizacion de mas bajo nivel han propiciado la 
aparicion de otros esquemas de mas alto nivel que facilitan la imple- 
mentacion de soluciones concurrentes. 

En estos esquemas se encuadran lenguajes de programacion como 
Ada, pero tambien existen bibliotecas de mas alto nivel que incluyen 
tipos abstractos de datos orientados a la programacion concurrente. 
Con el objetivo de discutir, desde el punto de vista practice otra solu- 
cion distinta a la biblioteca Pthreads, el anexo C describe la biblioteca 
de hilos de ZeroC ICE, un middleware de comunicaciones orientado 
a objetos para el desarrollo de aplicaciones cliente/servidor, y los me- 
canismos de sincronizacion que esta proporciona. En este contexto, 
el lector puede apreciar, desde un punto de vista practico, como las 
soluciones estudiadas a nivel de proceso en otros capitulos se pueden 
reutilizar a la hora de interactuar con hilos haciendo uso del lenguaje 
de programacion C++. 

Finalmente, algunos de los problemas clasicos de sincronizacion ya 
estudiados, como por ejemplo los filosofos comensales o el problema 
del productor/consumidor, se resuelven haciendo uso de la biblioteca 
de hilos de ICE. Como se podra apreciar en dicho anexo, las soluciones 
de mas alto nivel suelen mejorar la legibilidad y la mantenibilidad del 
codigo fuente. 




La programacion concurrente esta asociada inherentemente a la 
ejecucion en paralelo de procesos o hilos. Con el objetivo de evi- 
tar una gestion incorrecta de secciones criticas, el programador 
hace uso de primitivas de sincronizacion que proporcionen una ex- 
clusion mutua en determinadas partes del codigo. De este modo, y 
aunque el comportamiento general de un sistema concurrente sea no 
determinista, el funcionamiento del mismo es correcto. 

No obstante, en determinadas situaciones o sistemas de compu- 
te es necesario establecer restricciones mas fuertes con el objetivo de 
limitar ese no determinismo mencionado anteriormente. Por ejemplo, 
podria ser deseable limitar el tiempo maximo de respuesta de un pro- 
ceso ya que, por ejemplo, una respuesta demasiado tardia podria ser 
innecesaria o incluso no permitida considerando los requisitos del pro- 
blema a resolver. 

En este capitulo se aborda la problematica de la planificacion, en el 
contexto particular de los sistemas de tiempo real, como mecanismo 
general para establecer un determinismo en la ejecucion de progra- 
mas concurrentes. Para ello, se introduce la nocion de tiempo real y, 
a continuacion, se discuten algunos esquemas representatives de pla- 
nificacion en tiempo real. 
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5.1. In t roduc cion 



La ejecucion de tareas, procesos o hilos esta asociada, desde un 
punto de vista general, al i) nucleo de un sistema operativo, como por 
ejemplo Linux, o a ii) un entorno de ejecucion asociado a un lenguaje 
concreto, como por ejemplo Ada o Java. 

Desde una perspectiva general, en ambos casos se persigue un au- 
mento de la productividad. Como ejemplo particular, considere un 
sistema operativo multi-tarea instalado en un smartphone con un pro- 
cesador que esta compuesto de dos nucleos fisicos de ejecucion. En 
este contexto, sera posible ejecutar de manera paralela, por ejemplo, 
un navegador web y el despliegue de la agente del telefono. De este mo- 
do, la productividad aumenta aunque el tiempo medio de respuesta se 
vea afectado. 

El resultado de la ejecucion concurrente de diversos programas es- 
ta asociado a un modelo no determinista, en el sentido de que no sera 
posible determinar a priori la secuencia de ejecucion de los programas 
involucrados tras multiples ejecuciones de los mismos. En otras pala- 
bras, no existe a priori una garantia de que el proceso pi se ejecute en 
un deter minado At. 

Desafortunadamente, en sistemas con restricciones temporales 
existe una necesidad de determinismo que condiciona la propia eje- 
cucion de los procesos involucrados. Por ejemplo, considere el sistema 
de eyeccion en un avion de combate y la necesidad del piloto de aban- 
donar el avion ante una situacion de extrema emergencia. Evidente- 
mente, el tiempo de respuesta de dicho sistema ha de estar acotado 
por un umbral maximo. 

En situaciones de este tipo, con una naturaleza temporal mas res- 
trictiva, suele ser necesario utilizar algun tipo de herramienta o inclu- 
so lenguaje de programacion que de soporte a este control temporal. 
En la siguiente seccion se discute la nocion de tiempo real en un con- 
texto de programacion concurrente. 



5.2. El concepto de tiempo real 

Tradicionalmente, la nocion de tiempo real ha estado vinculada a 
sistemas empotrados como aspecto esencial en su funcionamiento. 
Como ejemplo clasico, considere el sistema de airbag de un coche. Si 
se produce un accidente, el sistema ha de garantizar que empleara co- 
mo maximo un tiempo At. Si no es asi, dicho sistema sera totalmente 
ineficaz y las consecuencias del accidente pueden ser catastroficas. 

Hasta ahora, y dentro del contexto de una asignatura vinculada a 
la Programacion Concurrente y Tiempo Real, este tipo de restricciones 
no se ha considerado y se ha pospuesto debido a que, normalmente, 
el control del tiempo real suele estar construido sobre el modelo de 
concurrencia de un lenguaje de programacion [3]. 




Figura 5.1: Actualmente, el 
concepto de multi-tarea, uni- 
do a la proliferacion de pro- 
cesadores multi-nucleo, es 
esencial para incrementar la 
productividad de los siste- 
mas software. 



Herramienta adecuada 



Benjamin Franklin llego a 
afirmar que si tuviera que 
emplear 8 horas en talar un 
arbol, usaria 6 para afilar el 
hacha. Ellja siempre la he- 
rramienta mas adecuada pa- 
ra soluclonar un problema. 
En el contexto de la pro- 
gramacion en tiempo real, 
exlsten entornos y lenguajes 
de programacion, como por 
ejemplo Ada, que proporcio- 
nan un gran soporte al desa- 
rrollo de este tipo de solucio- 
nes. 



5.2. El concepto de tiempo real 
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Figura 5.2: El control del 
tiempo es un aspecto esen- 
clal en el ambito de la progra- 
macion en tiempo real. 



En el ambito del uso de un lenguaje de programacion, la nocion de 
tiempo se puede describir en base a tres elementos independientes [3]: 

■ Interfaz con el tiempo, vinculada al uso de mecanismos de 

representacion de conceptos temporales. Por ejemplo, y como se 
discutira en breve, considere el uso de una estructura de datos 
de alto nivel para manejar retardos o delays. 

■ Representacion de requisitos temporales. Por ejemplo, consi- 
dere la necesidad de establecer un tiempo maximo de respuesta 
para un sistema empotrado. 

■ Satisfaccion de requisitos temporales, vinculada tradicional- 
mente a la planificacion de procesos. Tipicamente, la satisfaccion 
de dicho requisitos considerara el comportamiento del sistema en 
el peor caso posible con el objetivo de calcular una cota superior. 



o 



La notation Landau 0(f(x)) se refiere al conjunto de funclones 
que acotan superiormente a f(x). Es un planteamiento pesi- 
mista que consldera el comportamiento de una funcion en el 
peor caso posible. En el ambito de la planificacion en tiempo 
real se sigue esta filosofia. 



5.2.1. Mecanismos de representacion 

Relojes 

Dentro de un contexto temporal, una de los aspectos esenciales 
esta asociado al concepto de reloj. Desde el punto de vista de la pro- 
gramacion, un programa tendra la necesidad de obtener informacion 
basica vinculada con el tiempo, como por ejemplo la hora o el tiempo 
que ha transcurrido desde la ocurrencia de un evento. Dicha funcio- 
nalidad se puede conseguir mediante dos caminos distintos: 

■ Accediendo al marco temporal del entorno. 

■ Utilizando un reloj hardware externo que sirva como referencia. 

La primera opcion no es muy comun debido a que el propio entorno 
necesitaria, por ejemplo, llevar a cabo una sincronizacion con el reloj a 
traves de interrupciones. La segunda opcion es mas plausible desde la 
perspectiva del programador, ya que la informacion temporal se puede 
obtener mediante las primitivas proporcionadas por un lenguaje de 
programacion o incluso a traves del controlador de un reloj interno o 
externo. 

Esta segunda opcion puede parecer muy sencilla y practica, pe- 
ro puede no ser suficiente en determinados contextos. Por ejemplo, 
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la programacion de sistemas distribuidos puede plantear ciertas com- 
plicaciones a la hora de manejar una unica referenda temporal por 
varios servicios. Por ejemplo, considere que los servicios que confor- 
man el sistema distribuido se ejecutan en tres maquinas diferentes. En 
esta situacion, la referenda temporal de dichos servicios sera diferen- 
te (aunque probablemente minima). Para abordar esta problematica, 
se suele definir un serviolor de tiempo que proporcione una referenda 
temporal comun al resto de servicios. En esencia, el esquema se basa 
en la misma solucion que garantiza un reloj interno o externo, es decir, 
se basa en garantizar que la informacion temporal este sincronizada. 



OEn sistemas POSIX, la referenda temporal se mide en segundos 
desde el 1 de Enero de 1970. 



Retomando el reloj como referencia temporal comun, es importan- 
te resaltar diversos aspectos asociados al mismo, como la resolucion o 
precision del mismo (por ejemplo 1 segundo o 1 microsegundo) , el ran- 
go de valores que es capaz de representar y la exactitud o estabilidad 
que tiene. 

Desde el punto de vista de la programacion, cada lenguaje suele 
proporcionar su propia abstraccion de reloj. Por ejemplo, Ada pro- 
porciona dos paquetes vinculados a dicha abstraccion: 

■ Calendar, paquete de biblioteca obligatorio que proporciona es- 
tructuras de datos y funciones basicas relativas al tratamiento 
del tiempo. 

■ Real_Time, paquete de biblioteca opcional que proporciona un 
nivel de granularidad mayor, entre otras aspectos, que Calendar. 

El paquete Calendar en Ada implemente el tipo abstracto de datos 
Time, el cual representa un reloj para leer el tiempo. Asi mismo, dicho 
tipo mantiene una serie de funciones para efectuar conversiones entre 
elementos de tipo Time y otras unidades de tiempo asociadas a tipos 
del lenguaje, como el tipo entero usado para representar afios, meses 
o dias, o el tipo Duration usado para representar segundos. Por otra 
parte, Time tambien proporciona operadores aritmeticos que sirven 
para combinar parametros de tipo Duration y Time y para comparar 
valores de tipo Time. 

El tipo abstracto de datos Time es un ejemplo representative de 
herramienta, proporcionada en este caso por el lenguaje de programa- 
cion Ada, para facilitar el tratamiento de informacion temporal. 

A continuacion se muestra un listado de codigo que permite medir 
el tiempo empleado en llevar a cabo una serie de computes. Como se 
puede apreciar, Clock permite obtener referencias temporales (lineas 
{s} y (TJ) y es posible utilizar el operador de resta para obtener un valor 
de tipo Duration al restar dos elementos del tipo Time (linea (To)). 



5.2. El concepto de tiempo real 
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Listado 5.1: Midiendo el tiempo en Ada 95. 



1 


declare 




2 


T_Inicial, 


T_Final : Time; 


3 


Intervalo 


: Duration; 


4 


begin 




5 


T_Inicial 


:= Clock; 


6 


-- Aqui llamadas a funciones 


7 


— y otros 


calculos . 


8 


T_Final := 


Clock; 


9 


Uso de 


operador - 


10 


Intervalo 


:= T_Final - T_Inicial. 



11 end 



Por otra parte, el paquete RealJTime de Ada es similar a Calendar 
pero con algunas diferencias resectables. Por ejemplo, mantiene un 
nivel de granularidad mayor, hace uso de una constante Time_Un.it, 
que es la cantidad menor de tiempo representada por Time, y el rango 
de Time ha de ser de al menos 50 anos. En resumen, este paquete 
representa un nivel de resolucion mayor con respecto a Calendar. 

Retardos 

El reloj representa el elemento basico a utilizar por los procesos 
para poder obtener informacion temporal. Sin embargo, otro aspecto 
esencial reside en la capacidad de un proceso, tarea o hilo para sus- 
pend erse durante un determinado instante de tiempo. Esta situacion 
esta asociada al concepto de retardo o retraso. Desde un punto de 
vista general, los retardos pueden clasificarse en dos tipos: 

■ Relativos, los cuales permiten la suspension respecto al instante 
actual. Por ejemplo, es posible definir un retardo relativo de 2 
segundos. 

■ Absolutos, los cuales permiten retrasar la reanudacion de un 
proceso hasta un instante de tiempo absolute Por ejemplo, po- 
dria ser necesario garantizar que una accion ha de ejecutarse 5 
segundos despues del comienzo de otra accion. 

En Ada, un retardo relativo se puede implementar facilmente me- 
diante un bucle de manera que, en cada iteracion, el programa com- 
pruebe si han transcurrido los n segundos asociados al retardo. El 
siguiente listado de codigo muestra un posible ejemplo asociado a un 
retraso relativo de 7 segundos. 



Listado 5.2: Ejemplo de retardo relativo en Ada. 



: Inicio := Clock; 

2 

loop 

exit when (Clock - Inicio) > 7.0; 
5 end loop; 



El principal problema de este planteamiento es la espera activa, 
concepto discutido inicialmente en la seccion 1.2.2. En este contexto, 
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algunos lenguajes de programacion incluyen primitivas que eviten este 
problema. Por ejemplo, Ada introduce la sentencia delay para efectuar 
un retardo relative-: 



Listado 5.3: Uso de delay en Ada. 



delay 7.0; 



En POSIX, los retardos relativos se pueden implementar a traves 
de primitivas como sleep o nanosleep, en funcion del nivel de granu- 
ralidad deseado por el programador. Estas primitivas garantizan que 
el proceso que las invoco sera ejecutable despues de que transcurra el 
periodo de tiempo indicado como argumento. 



La primitiva sleep suspende el hilo de ejecucion que realiza la 
llamada hasta que pasa el tiempo indicado o hasta que recibe 
una serial no ignorada por el programa. No olvide contemplar 
este ultimo caso en sus programas. 



Por otra parte, un retardo absoluto tiene una complejidad anadida 
en el sentido de que puede ser necesario calcular el periodo a retrasar 
o, en funcion del lenguaje de programacion utilizado, emplear una 
primitiva adicional. 

Considere la situacion en la que una accion ha de tener lugar 7 
segundos despues del comienzo de otra. El siguiente fragmento de 
codigo en Ada plantea una posible solucion. 



Listado 5.4: Intento de retraso absoluto en Ada. 



Accion_l; Ejecucion de Accion 1. 
delay 7.0; 

Accion_2; Ejecucion de Accion 2. 



Este primer planteamiento seria incorrecto, debido a que los 7 se- 
gundos de espera se realizan despues de la finalizacion de Accion_l, 
sin considerar el instante de comienzo de la ejecucion de esta. 

El siguiente listado contempla esta problematica. Como se puede 
apreciar, la variable Transcurrido de la linea (T) almacena el tiempo 
empleado en ejecutar Accion_l. De este modo, es posible realizar un 
retraso de 7,0 — Transcurrido segundos (linea (Tj) antes de ejecutar Ac- 
cion_2. 

Desafortunadamente, este planteamiento puede no ser correcto ya 
que la instruccion de la linea (T) no es atomica, es decir, no se ejecuta 
en un instante de tiempo indivisible. Por ejemplo, considere la situa- 
cion en la que Accion l consume 2 segundos. En este caso en con- 
creto, 7,0 — Transcurrido deberia equivaler a 5,0. Sin embargo, si justo 
despues de realizar este calculo se produce un cambio de contexto, el 
retraso se incrementaria mas alia de los 5,0 segundos calculados. 
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Listado 5.5: Retraso absoluto en Ada. 



Inicio := Clock; 

Accion_l; Ejecucion de Accion 1. 

Transcurrido := Clock - Inicio; 

4 

delay 7.0 - (Transcurrido); 

6 

Accion_2; — Ejecucion de Accion 2. 



Algunos lenguajes de programacion introducen sentencias especifl- 
cas que permiten gestionar este tipo de retardos absolutos. En el caso 
particular de Ada, esta sentencia esta representada por la construc- 
cion delay until <Time>: 

Note como delay until establece un limite inferior, el propio retraso 
absoluto, antes de que AccionJZ se ejecute. No obstante, esta solucion 
no contempla la posibilidad de que Accion_l tarde mas de 7 segundos 
en ejecutarse. 



Listado 5.6: Uso de delay until en Ada. 



1 Inicio := Clock; 

Accion_l; Ejecucion de Accion 1. 

3 

delay until (Inicio + 7.0); 

5 

Accion_2; — Ejecucion de Accion 2. 



Tanto en retardos absolutos como en retardos relativos, el tiempo 
sobrepasado se denomina deriva local y no es posible eliminarlo [3]. 
Sin embargo, es posible combatir este problema eliminando la deriva 
acumulada que se produce cuando las derivas locales se superponen. 



Llamada 

i 

update () 



Llamada 

2 

updateQ 



Llamada 

3 

updateQ 



4.4*' 



3.6' 



Figura 5.3: Ejemplo de control de la deriva acumulada. Las llamadas a update se reali- 
zan cada 4 segundos de media. 



Por ejemplo, considere que es necesario realizar una llamada a una 
funcion update cada 4 segundos de media para evitar la deriva local 
que se vaya acumulando (ver figura 5.3). El siguiente listado de codigo 
muestra una posible solucion utilizando Ada. 

Como se puede apreciar, la sentencia delay until combinada con la 
actualizacion de SiguienteLlamada (lineas ( 12-13 )) permite eliminar la 
deriva acumulada y realizar llamadas a update cada 4 segundos. 
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Listado 5.7: Gestion de la deriva acumulada en Ada. 



declare 

2 SiguienteLlamada : Time; 

3 — Tiempo medio de actualizacion . 
Intervalo : constant Duration 5.0; 

5 

begin 

SiguienteLlamada := Clock + Intervalo; 

8 

loop 

Update; 

11 — Retraso absoluto. 

12 delay until SiguienteLlamada; 
SiguienteLlamada := SiguienteLlamada + Intervalo; 

14 end loop; 

15 

.6 end; 



Finalmente, resulta interesante destacar algunos factores relevan- 
tes que afectan a los retardos y que hay que considerar: 

■ La granularidad del retardo y la del reloj pueden ser distintas. 
Por ejemplo, POSIX soporta una granularidad hasta el nivel de 
los nanosegundos, mientras que es posible que el reloj de algun 
sistema no llegue hasta dicho nivel. 

■ El propio reloj interno puede verse afectado si se implementa me- 
diante un mecanismo basado en interrupciones que puede ser 
inhibido durante algun instante de tiempo. 



5.2.2. Control de requisitos temporales 

En el ambito de la programacion de sistemas de tiempo real, el con- 
trol de requisitos temporales es esencial para garantizar un adecuado 
funcionamiento del sistema. Una de las restricciones mas simples que 
puede tener un sistema empotrado es identiflcar y actuar en conse- 
cuencia cuando un determinado evento no tiene lugar. 

Por ejemplo, considere que un sensor de temperatura ha de realizar 
una comprobacion de la misma cada segundo. Sin embargo, y debido 
a cualquier tipo de problema, esta comprobacion puede fallar y no 
realizarse en un determinado intervalo de tiempo. En este contexto, el 
sistema podria tener definido un tiempo de espera h'mite o timeout 
de manera que, si este expira, el sistema pueda emitir una situacion 
de fallo. 

Otro posible ejemplo consistiria en garantizar que un determinado 
fragmento de codigo no tarde en ejecutarse mas de un tiempo pre- 
definido. De no ser asi, el programa deberia ser capaz de lanzar un 
mecanismo de recuperacion de errores o una excepcion. 
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Recuerde que cuando un proceso esta ejecutando una seccion 
critica, es bastante probable que otros procesos se encuentren 
bloqueados para poder acceder a la misma. En determinadas 
situaciones, sera deseable controlar el tiempo maxlmo que un 
proceso puede estar en una seccion critica. 



Hasta ahora, y dentro del contexto de la programacion concurren- 
te, no se ha controlado el tiempo empleado por un proceso o hilo en 
acceder, de manera exclusiva, a la seccion critica. En otras palabras, 
aunque un proceso obtenga el acceso exclusivo a una determinada 
seccion de codigo, es deseable controlar el tiempo maximo que puede 
invertir en dicha seccion. En esencia, esta gestion esta asociada a un 
control de los requisitos temporales. 

POSIX considera en algunas de sus primitivas un tiempo limite pa- 
ra acceder a la seccion critica. Por ejemplo, la primitiva de POSIX pth- 
read_cond_timedwa.it devuelve un error si el tiempo absoluto indicado 
en uno de sus argumentos se alcanza antes de que un hilo haya rea- 
lizado un signal o broadcast sobre la variable de condicion asociada 
(vea seccion 4.3.1). 



Listado 5.8: Primitiva pthread cond timedwait. 



#include <pthread.h> 

2 

int pthread_cond_timedwait (pthread_cond_t ^restrict cond, 
pthread_mutex_t ^restrict mutex, 
const struct timespec *restrict abstime) ; 

6 

int pthread_cond_wait (pthread_cond_t *restrict cond, 
pthread_mutex_t ^restrict mutex) ; 



Desafortunadamente, este tipo de bloqueo no es facilmente limi- 
table ya que mantiene una fuerte dependencia con la aplicacion en 
cuestion. Por ejemplo, en el problema del buffer limitado se puede dar 
la situacion de que los productores se bloqueen a la espera de que 
los consumidores obtengan algun elemento del buffer. Sin embargo, 
puede ser que estos no esten preparadas hasta mas adelante para 
obtener informacion. En este contexto, el productor deberia limitar el 
tiempo de espera asociado, por ejemplo, al decremento del valor de un 
semaforo. 

El siguiente listado de codigo muestra como hacer uso de la primi- 
tiva sem_timedwait de POSIX para tratar esta problematica. 
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Listado 5.9: Limitando el tiempo de bloqueo en un semaforo. 



if ( sem_timedwait (empty, tiempo) < 0) { 
if (errno == ETIMEDOUT) { 

3 // Tiempo cumplido. 

} 

5 else { 

6 // Otro error. 

7 } 

else { 

9 // Decremento realizado. 
10 } 



Otro concepto importante en el ambito del control de requisitos 
temporales es el concepto de evento disparador, el cual permite abor- 
tar una accion si dicho evento ocurre antes. Tipicamente, el evento 
disparador estara asociado al paso de un incremento de tiempo. 

El siguiente listado de codigo muestra un ejemplo en Ada que limita 
el tiempo maximo de ejecucion de una tarea a 0.25 segundos mediante 
un evento disparador. 



Listado 5. 10: Ejemplo de evento disparador en Ada. 



l select 

delay 0.25; 
3 then abort 

TareaA; 
end select; 



Este tipo de esquemas permite captura codigo descontrolado, aco- 
tando superiormente el tiempo de ejecucion que puede consumir. 




Recuerde que los tiempos limite de espera se suelen asociar con 
condiciones de error. 



Finalmente, y antes de pasar a la siguiente seccion en la que se 
discutiran distintas opciones de planificacion en tiempo real, es im- 
portante destacar, como principal conclusion, que en ocasiones no es 
suficiente con que el software sea logicamente correcto. Ademas, este 
ha de satisfacer ciertas restricciones temporales, es decir, es necesario 
contemplar el contexto temporal en el que se ejecuta un sistema. 

5.3. Esquemas de planificacion 

Como ya se introdujo anteriormente en la seccion 5. 1, en un siste- 
ma concurrente no existe, generalmente, una necesidad real de espe- 
cificar el orden exacto en el que se ejecutan los distintos procesos que 
participan en el mismo. 
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Hasta ahora, las restricciones de orden vinculadas a las necesida- 
des de sincronizacion de los problemas discutidos se han modelado a 
traves del uso de semaforos, monitores o incluso colas de mensajes. 
Por ejemplo, si recuerda el problema de la barberia discutido en la 
seccion 2.3.5, el cliente tenia que despertar al barbero antes de que 
este efectuara la accion de cortar. Esta interaccion se llevaba a cabo 
mediante un signal sobre el semaforo correspondiente. 

No obstante, el comportamiento global de la simulacion de la bar- 
beria no era determinista. Por ejemplo, ante distintas ejecuciones con 
el mismo numero inicial de clientes, el resultado seria distinto debido 
a que el orden de ejecucion de las distintas acciones que conforman 
cada proceso variaria de una simulacion con respecto a otra. 

Desde una perspectiva general, un sistema concurrente formado 
por n procesos tendra nl formas distintas de ejecutarse en un procesa- 
dor, suponiendo un esquema no apropiativo. En esencia, y aunque el 
resultado final sea el mismo, el comportamiento temporal de los dis- 
tintos procesos varia considerablemente [3]. Asi, si uno de los procesos 
tiene impuesto un requisite temporal, entonces solamente lo cumplira 
en aquellos casos en los que se ejecute al principio. 

Un sistema de tiempo real necesita controlar este no determinismo 
a traves de algun mecanismo que garantice que los distintos proce- 
sos ejecutan sus tareas en el plazo y con las restricciones previamente 
definidas. Este mecanismo se conoce tradicionalmente como planifi- 
cacion o scheduling. 




La planificacion estatica es la que se basa en realizar una pre- 
diccion antes de la ejecucion del sistema, mientras que la dina- 
mica se basa en tomar decisiones en tiempo de ejecucion. 



En un esquema de planificacion se pueden distinguir dos elementos 
relevantes [3]: 

1. Un algoritmo para ordenar el uso de los recursos del sistema, 
tipicamente las CPU. 

2. Un mecanismo para predecir el comportamiento del sistema cuan- 
do se aplica el algoritmo anterior. Normalmente, la prediccion se 
basa en un planteamiento pesimista, es decir, considera el peor 
escenario posible para establecer una cota superior. Este tipo de 
mecanismos permiten conocer si los requisitos temporales esta- 
blecidos para el sistema se cumpliran o no. 

Conceptos relevantes en un esquema de planificacion 

Antes de llevar a cabo una discusion de distintas alternativas exis- 
tentes para realizar la planificacion de un sistema, resulta importante 
enumerar ciertos parametros que son esenciales para acometer dicha 
tarea. 
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■ Tiempo maximo de ejecucion (C), tiempo de ejecucion de un 
proceso en el peor de los casos (worst-case execution time o WCET). 

■ Interferencia (I), tiempo de interferencia del proceso, es decir, el 
tiempo que acumula un proceso como consecuencia de la inte- 
rrupcion de otros. 

■ Bloqueo (B), tiempo de bloqueo del proceso en el peor caso (si 
es aplicable). Por ejemplo, considere el tiempo que un proceso 
se bloquea como consecuencia de una llamada a wait sobre un 
semaforo. 

■ Deadline (D), tiempo limite de ejecucion para un proceso, es de- 
cir, el tiempo maximo que pueda transcurrir antes de que finalice 
su ejecucion. 

■ Tiempo de respuesta (R), tiempo de respuesta de un proceso en 
el peor caso (si es aplicable). 

■ Periodo (T), tiempo minimo entre dos ejecuciones del proceso. 

■ Prioridad (P), valor numero que denota la importancia de un pro- 
ceso. 

Por otra parte, las tareas se pueden clasificar en periodicas, si se 
ejecutan con un periodo determinado, o esporadicas, si se ejecutan 
atendiendo a un evento temporal que las activa. 



Como se discutira posteriormente, en un sistema de tiempo real 
el objetivo principal consiste en garantizar que los tiempos de 
respuesta de todas las tareas sean menores a sus respectivos 
deadlines. Por el contrario, en un sistema que no es de tiempo 
real, uno de los objetivos principales consiste en minimizar el 
tiempo de respuesta de las tareas involucradas. 




5.3.1. Modelo simple de tareas 

En esta seccion se describen los fundamentos de un modelo sim- 
ple de tareas [3] que sirva como base para discutir los aspectos mas 
importante de un sistema de planificacion. Sobre este modelo se iran 
afiadiendo distintas caracteristicas que tendran como resultado varia- 
ciones en el esquema de planificacion inicial. 

Las principales caracteristicas de este modelo inicial son las si- 
guientes: 

■ El numero de procesos involucrados en la planificacion es fijo. 

■ Todos los procesos son periodicos y su periodo (T) se conoce a 
priori. 



5.3. Esquemas de planificacion 
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■ Todos los procesos son independientes entre si. 

■ No se consideran tiempos asociados a eventos como cambios de 
contexto. 

■ El deadline (D) de todos los procesos es igual a su periodo. En 
otras palabras, todo proceso ha de completarse antes de volver a 
ejecutarse de nuevo. 

■ El esquema de asignacion de prioridades es estatico. 

■ Es posible desalojar a una tarea si existe otra con mayor priori- 
dad lista para ejecutarse. 

■ El tiempo maximo de ejecucion de cada tarea (C) es conocido. 




La independencia de los procesos en el modelo simple posibili- 
ta que todos se ejecuten en paralelo, llevando al sistema a su 
carga maximo y generando un instante critico. 



5.3.2. El ejecutivo ciclico 

El primer esquema de planificacion a discutir se denomina ejecu- 
tivo ciclico debido al mecanismo utilizado para ejecutar las distintas 
tareas involucradas en la planificacion. En esencia, el objetivo a alcan- 
zar consiste en definir un modelo de planificacion para un conjunto de 
tareas que se pueda repetir a lo largo del tiempo, de manera que todas 
ellas se ejecuten con una tasa apropiada. 

Cuando se hace uso de este esquema no existe nocion alguna de 
concurrencia, ya que las tareas son procedimientos que se planifican 
para que cumplan sus respectivos deadlines. Tipicamente, el ejecutivo 
ciclico se modela como una tabla de llamadas a procedimientos. 

Esta tabla representa el concepto de hiperperiodo o ciclo princi- 
pal, dividido a su vez en una serie de ciclos secundarios de duracion 
fija. El calculo del ciclo principal (T m ) se realiza obteniendo el minimo 
comun multiplo de los periodos de todos los procesos, es decir, 

T m = m.c.m(Ti, i e {1,2, . . . , n}) (5.1) 

mientras que el calculo del ciclo secundario (T s ) se realiza mediante 
aproximacion con el menor periodo de todos los procesos a planificar. 

La planificacion mediante ejecutivo ciclico se basa en colocar en ca- 
da ciclo secundario las tareas para garantizar que cumplan sus deadli- 
nes. La figura 5.5 muestra de manera grafica el resultado de planificar 
el conjunto de procesos que contiene la tabla 5.1. 
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T = 200 ms 



T = 50 ms 



50 



100 



150 



200 



Figura 5.5: Esquema grafico de planificacion segun el enfoque de ejecutivo ciclico para 
el conjunto de procesos de la tabla 5.1. 



Proceso 


Periodo (T) 


Tiempo de ejecucion (C) 


a 


50 


20 


b 


50 


16 


c 


100 


10 


d 


100 


8 


e 


200 


4 



Tabla 5.1: Datos de un conjunto de procesos para llevar a cabo la planificacion en base 
a un ejecutivo ciclico. 



Como se puede apreciar, el esquema de planificacion es simple y 
consiste en ir asignando los procesos a los distintos slots tempora- 
les que vienen determinados por el valor del ciclo secundario. En este 
ejemplo en concreto, el valor del ciclo principal es de 200 ms (mini- 
mo comun multiplo de los procesos), mientras que el valor del ciclo 
secundario es de 50 ms (menor periodo de un proceso). 

Note como el esquema de planificacion garantiza que todos los pro- 
cesos cumplan sus deadlines. Ademas, la planificacion de un ciclo 
completo (200 ms) garantiza que el esquema es completo en sucesivos 
hiperperiodos (en sucesivos bloques de 200 ms), ya que la ejecucion 
de los procesos no variara. Desde el punto de vista del funcionamiento 
interno, se producira una interrupcion de reloj cada 50 ms, de manera 
que el planificador realiza rondas entre los cuatro ciclos secundarios 
que componen el hiperperiodo. 

El uso de un enfoque de ejecutivo ciclico presenta consecuencias 
relevantes asociadas a las caracteristicas inherentes al mismo [3]: 

■ Cada ciclo secundario es una secuencia de llamadas a procedi- 
mientos (los procesos no existen en tiempo de ejecucion), como 
se muestra en la figura 5.6. 
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■ No existe la necesidad de gestionar el acceso exclusivo a recursos, 
ya que los procesos nunca se ejecutan en paralelo. 

■ Los periodos de todos los procesos han de ser multiplo del ciclo 
secundario. 



do { 














interrupcion ; 


llamada 


a; 


llamada 


_b; 


llamada 


c; 


interrupcion; 


llamada 


a; 


llamada 


Jo; 


llamada 


d; llamada e; 


interrupcion; 


llamada 


a; 


llamada 


Jo; 


llamada 


_c; 


interrupcion ; 


llamada 


a; 


llamada 


Jo; 


llamada 


_d; 


while (1) ; 















Figura 5.6: El codigo asociado al ejecutivo ciclico consiste simplemente en un bucle con 
llamadas a procedimientos en un determinado orden. 



Precisamente, esta ultima consecuencia es la desencadenante de 
gran parte de las limitaciones de este enfoque: 

■ La integracion de procesos no periodicos, es decir, esporadicos, 
no es sencilla. 

■ Los procesos con periodos elevados causan problemas de planifi- 
cacion. 

■ La construccion del ejecutivo ciclico es tediosa, sobre todo si el 
numero de procesos es significativo. 

■ La integracion de procesos con un tiempo de ejecucion elevado 
es problematica y propensa a errores, debido a la necesidad de 
fragmentarlos en unidades de ejecucion. 

Aunque cuando se usa el ejecutivo ciclico no es necesario ningun 
test de planificabilidad adicional, su construccion es problematica, 

especialmente en sistemas de alta utilizacion. En terminos de com- 
plejidad computacional, dicha construccion es similar a problemas de 
optimizacion clasicos, como por ejemplo el problema de la mochila. 
Este tipo de problemas son NP-completos y tienen una complejidad 
exponencial, siendo irresolubles para problemas de un cierto tamano. 
En sistemas reales, es posible encontrarse con 50 ciclos secundarios y 
unas 500 entradas en la tabla del ejecutivo, por lo que es necesario ha- 
cer uso de heuristicas que obtengan buenas soluciones para construir 
el propio ejecutivo. 

En conclusion, el ejecutivo ciclico puede ser una alternativa viable 
para sistemas con un numero determinado de procesos periodicos. 
Sin embargo, su baja flexibilidad hace que los sistemas basados en 
la planificacion de procesos, como los que se discuten en la siguiente 
seccion, sean mas adecuados. 
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5.3.3. Planificacion basada en procesos 

La planificacion mediante ejecutivo ciclico no contempla la ejecu- 
cion de procesos o hilos durante la ejecucion, es decir, no hay una 
nocion de concurrencia. Un planteamiento totalmente diferente con- 
siste en soportar la ejecucion de procesos, al igual que ocurre en los 
sistemas operativos modernos. En este contexto, la respuesta a res- 
ponder es ^Cudl es elproceso a ejecutar en cada momento?. 

En base a este planteamiento, un proceso puede estar en ejecu- 
cion o esperando la ocurrencia de algun tipo de evento en un estado 
de suspension. En el caso de procesos periodicos, este evento esta- 
ra temporizado, mientras que en el casode procesos no periodicos o 
esporadicos, dicho evento no estara temporizado. 

Aunque existe una gran variedad de alternativas de planificacion, 
en el presente capitulo se contemplaran las dos siguientes: 

1. Fixed Priority Scheduling (FPS), planificacion por prioridad es- 
tatica. 

2. Earliest Deadline First (EDF), planificacion por tiempo limite 
mas cercano. 

El esquema FPS es uno de los mas utilizados y tiene su base en 
calcular, antes de la ejecucion, la prioridad Pi de un proceso. Dicha 
prioridad es fija y estatica. Asi, una vez calculada la prioridad de todos 
los procesos, en funcion de un determinado criterio, es posible esta- 
blecer una ejecucion por orden de prioridad. En sistemas de tiempo 
real, este criterio se define en base a los requisitos de temporizacion. 

Por otra parte, el esquema EDF se basa en que el proximo proceso 
a ejecutar es aquel que tenga un menor deadline B l absoluto. Nor- 
malmente, el deadline relativo se conoce a priori (por ejemplo, 50 ms 
despues del comienzo de la ejecucion del proceso), pero el absoluto se 
calcula en tiempo de ejecucion, concediendo una naturaleza dinamica 
a este tipo de esquema de planificacion. 

Antes de pasar a discutir los aspecto relevantes de un planificador, 
es importance considerar la nocion de apropiacion en el contexto de 
una planificacion basada en prioridades. Recuerde que, cuando se uti- 
liza un esquema apropiativo, es posible que un proceso en ejecucion 
con una baja prioridad sea desalojado por otro proceso de mas alta 
prioridad, debido a que este ultimo ha de ejecutarse con cierta ur- 
gencia. Tipicamente, los esquemas apropiativos suelen ser preferibles 
debido a que posibilitan la ejecucion inmediata de los procesos de alta 
prioridad. 



Existen modelos de apropiacion hibridos que permiten que un 
proceso de baja prioridad no sea desalojado por otro de alta 
hasta que no transcurra un tiempo limitado, como el modelo 
de apropiacion diferida. 




5.4. Aspectos relevantes de un planificador 



[139] 



5.4. Aspectos relevantes de un planificador 

Como ya se ha comentado anterior mente, el cometido principal de 
un planificador consiste en determinar en cada instante que tarea, de 
aquellas listas para ejecutarse, se ejecutara en la CPU. Para ello, y 
desde un punto de vista general, el planificador es el responsable de 
gestionar los siguientes elementos: 

■ Un sistema de asignacion de prioridades, responsable de esta- 
blecer la prioridad de los procesos en base a algun criterio (nor- 
malmente asociado a requisitos temporales) . 

■ Un modelo de analisis del tiempo de respuesta, responsable 
de calcular dicho tiempo para determinar si el sistema es planifi- 
cable de acuerdo a las restricciones temporales impuestas por el 
entorno. 




Un sistema de tiempo real es planificable si los tiempos de res- 
puesta de todos los procesos o tareas que lo componen son 
menores que sus respectivos deadlines. 



( ^ I 1 ( ^ 

Requisitos Modelo de analisis de ^Sistema 

temporales tiempo de respuesta planificable? 
\ ) I I V ) 

Figura 5.7: El principal cometido de un modelo de analisis del tiempo de respuesta es 
determinar si un sistema es planificable en base a sus requisitos temporales. 



La implementacion de este modelo de analisis se puede realizar de 
diversas formas, como por ejemplo mediante i) el calculo del denomi- 
nado factor de utilizacion que, aunque no es exacto, es simple y 
practico, ii) la generacion de un esquema grafico que muestre la pla- 
nificacion del sistema o iii) utilizando algun esquema matematico para 
el calculo del tiempo de respuesta. 

En las siguientes secciones se discutiran aspectos tanto del siste- 
ma de asignacion de prioridades como de cada una de las opciones 
mencionadas para implementar el modelo de analisis del tiempo de 
respuesta. 

5.4.1. Sistema de asignacion de prioridades 

Considerando el modelo simple introducido en la seccion 5.3.1, es 
posible establecer un esquema optimo de asignacion de prioridades 
denominado rate monotonic [tasa monotonica) [3]. Basicamente, a 
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cada proceso ■p l se le asigna una prioridad unica P l basada en el valor 
de su periodo T it de manera que los procesos con un periodo menor 
tendran una prioridad mas alta, 

Vi, j € {1, 2, . . . , n}(i ^ j),Ti < Tj ^P t > Pj (5.2) 

Este esquema de asignacion es optimo para un conjunto de proce- 
sos planificado mediante un esquema de prioridades estatico y apro- 
piativo. 

Note que en el modelo simple planteado anterior mente, el deadline 
de un proceso es igual a su periodo, es decir, D = T. Por lo tanto, este 
esquema de asignacion de prioridades coincide con el esquema Dead- 
line Monotonic Scheduling (DMS). La principal consecuencia es que 
los procesos o tareas con un menor deadline tendran una mayor prio- 
ridad. Este esquema es optimo para sistemas de tiempo real criticos, 
asumiendo el modelo simple con tareas esporadicas y bloqueos. 



5.4.2. Modelo de analisis del tiempo de respuesta 
Factor de utilizacion 

El concepto de factor de utilizacidn esta vinculado a un test de pla- 
nificabilidad que, aunque no es exacto, es muy simple y practice La 
base de este test se fundamenta en que, considerando la utilizacion 
de un conjunto de procesos, empleando el esquema FPS, se puede ga- 
rantizar un test de planificabilidad si se cumple la siguiente ecuacion 
para todos los procesos [7]: 



< - 1) ( 5 - 3 ) 

i=i 4 

El sumatorio de la parte izquierda de la ecuacion representa la uti- 
lizacion total del conjunto de procesos. Este valor se compara con el 
limite de utilizacidn que viene determinado por la parte derecha de la 
ecuacion. La siguiente tabla muestra el limite de utilizacion para algu- 
nos valores de N (numero de procesos). 



N (n° de procesos) 


Limite de utilizacion 


1 


1 


2 


0.828 


3 


0.78 


4 


0.757 


5 


0.743 


10 


0.718 



Tabla 5.2: Limite de utilizacion para distintos valores del numero de procesos (N) invo- 
lucrados en la planificacion. 
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En determinadas situaciones, los tests de planlflcabilidad no 
necesitan ser estrictamente precisos, sino que es suficiente con 
proporcionar una aproximacion realista. 



Para ejemplificar este sencillo test de planificabilidad, la siguiente 
tab la muestra 3 procesos con sus respectivos atributos. 



Proceso 


T 


C 


P 


U (Factor de utilizacion) 


a 


50 


10 


1 


0.2 


b 


40 


10 


2 


0.25 


c 


20 


5 


3 


0.25 



Tabla 5.3: Limite de utilizacion para distintos valores del numero de procesos (N) invo- 
lucrados en la planificacion. 



En el ejemplo de la tabla 5.3, la utilizacion total es de 0,7, valor 
menor a 0,78 (ver tabla 5.2), por lo que el sistema es planificable. 

Esquema grafico 

En la figura 5.5 ya se mostro un esquema grafico con el objetivo de 
mostrar un enfoque de planificacion basado en el ejecutivo ciclico. En 
concreto, dicho esquema grafico se corresponde con un diagrama de 
Gantt. 

Por otra parte, tambien es posible emplear un esquema grafico ba- 
sado en el uso de las denominadas lineas de tiempo. La figura 5.8 
muestra estos dos esquemas en relacion a los procesos de la tabla 
5.3. 

En el caso particular de las lineas de tiempo, es necesario plan- 
tearse hasta cuando es necesario trazar dichas lineas de tiempo para 
garantizar que ningun proceso incumple su deadline. La clave reside 
en dibujar una linea temporal igual al tamafio del periodo mas largo 
[7]. 




Si todos los procesos cumplen su primer deadline temporal, 
entonces lo cumpliran tambien en el futuro. 
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Proceso 



10 




20 



30 



(a) 



I I I 1 




40 



50 



Tiempo 




t 



10 



Instante de 
activacion 



20 



30 



| j En ejecucion j " "j Desalojado 

(b) 



Tiempo 



Instante de 
O finalizacion 



Figura 5.8: Distintos esquemas graficos utilizados para mostrar patrones de ejecucion 
para los procesos de la tabla 5.3. (a) Diagrama de Gantt. (b) Lineas de tiempo. 



Calculo del tiempo de respuesta 

Aunque los tests basados en la utilizacion y los esquemas grafi- 
cos discutidos en las anteriores secciones son mecanismos sencillos y 
practicos para determinar si un sistema es planificable, no son escala- 
bles a un numero de procesos relevante y plantean ciertas limitaciones 
que hacen que sean poco flexibles. Por lo tanto, es necesario plan- 
tear algun otro esquema que sea mas general y que posibilite afiadir 
mas complejidad al modelo simple de tareas introducido en la seccion 
5.3.1. 

En esta seccion se discute un esquema basado en dos pasos bien 
diferenciados: 



1. Calculo del tiempo de respuesta de todos los procesos mediante 
una aproximacion analitica. 
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2. Comparacion del tiempo de respuesta de todos los procesos con 
sus respectivos deadlines. 



Estos dos pasos sirven para comprobar la expresion 

R l < Dtfi e {l,2,...,n} 



(5.4) 



f 



Calculo R. 



Para todo p.. 



;P. <=r? 



Sistema 
planificable 



Figura 5.9: Esquema grafico de un esquema de analisis del tiempo de respuesta para 
un conjunto de procesos o tareas. 



es decir, si el tiempo de respuesta Ri de todo proceso es menor a su 
deadline di, entonces se puede afirmar que el sistema es planifica- 
ble. En otras palabras, se puede afirmar que todo proceso pi cumplira 
sus requisitos temporales. Para llevar a cabo estas comparaciones se 
realiza un analisis individual a nivel de proceso. 

El caso mas sencillo en un esquema apropiativo basado en prio- 
ridades fijas esta representado por el proceso de mayor prioridad, ya 
que este no recibira ninguna interrupcion por ningun otro proceso. 
En el peor de los casos, el tiempo de respuesta de dicho proceso sera 
igual al tiempo de ejecucion en el peor caso, es decir, R = C. Sin em- 
bargo, para cualquier otro proceso pi que pueda recibir interrupciones 
por parte de procesos de mayor prioridad, la expresion del tiempo de 
respuesta R t vendra determinada por 



Ri = Ci + h (5.5) 

donde es el tiempo asociado a la interferencia maxima que pi puede 
sufrir, como consecuencia de algun desalojo, en el intervalo de tiempo 

[t,t + Ri\. 




La interferencia maxima sufrida por un proceso se da cuando 
todos los procesos que tienen una mayor prioridad se activan. 
Esta situacion se denomina instante critico. 



A continuacion se deducira el tiempo de interferencia de un pro- 
ceso pj. Para ello, suponga que todos los procesos se activan en un 
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mismo instante de tiempo, por ejemplo en el instante 0, y que existe 
un proceso pj con mayor prioridad que p it es decir, Pj > Pi. En este 
caso, el proceso pj sera activado un determinado numero de veces (al 
menos una) dentro del intervalo [0, Ri), es decir, dentro del intervalo 
en el que pi completara su ejecucion. Para obtener el numero de veces 
que pj se activa en dicho intervalo se puede emplear la ecuacion 

R ■ 

Activaciones = |~— ] (5.6) 

Informalmente, esta ecuacion permite calcular el numero de veces 
que el periodo de pj es menor al tiempo de respuesta de p it es decir, 
el numero de veces que pj interrumpira ap,. La funcion techo se usa 
para obtener el menor entero que sea mayor que el resultado de dicha 
division. Por ejemplo, si R t es 12 y Tj es 5, entonces se produciran tres 
activaciones de pj en los instantes 0, 5 y 10. 



Tiempo de respuesta p. (R ) 




\ T k 

j 


i T k 

j 


\ 

#Activaciones p 

j 



Figura 5. 10: Esquema grafica del numero de activaciones de un proceso pj con periodo 
Tj que interrumpe a un proceso p t con un tiempo de respuesta total Ri. 



A partir de este razonamiento, el calculo del tiempo total de inte- 
rrupcion de pj sobre pi es sencillo, ya que solo hay que considerar 
cuanto tiempo interrumpe pj a p^ en cada activacion. Dicho tiempo 
viene determinado por Cj, es decir, el tiempo de ejecucion de pj en el 
peor caso posible. Por lo tanto, la expresion de l l es la siguiente: 

U = f^l * ^ (5.7) 

En el ejemplo anterior, si Cj = 7, entonces /j sera igual a 21. 

Debido a que cada proceso de mas alta prioridad que p l puede in- 
terrumpirlo (al igual que hace pA, la expresion general de l l es la si- 
guiente: 

ii= £ (\^* Cj) (5 - 8) 

jehp(i) 3 

donde hp(i) representa el conjunto de procesos con mayor prioridad 
(higher priority) que p { . 
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Si se sustituye el resultado de la ecuacion 5.8 en la ecuacion 5.5, 
entonces se obtiene la expresion final de R4 : 

^ = c i+ J2 (r^i*^) (5.9) 

jeh P (i) j 

La ecuaclon 5.9 tiene la peculiaridad de que Ri aparece tanto en la 
parte izquierda como en la parte derecha de la misma. Sin embargo, 
dicha ecuacion se puede resolver mediante una relacion de recurren- 
cia mediante un proceso de iteracion: 

«\ 9 = Ci + £ (Cj) 

jehp(i) 

jeh P (i) j 
jeh P (i) j 

O en general: 

< = Ci+ E (H^l*^) (5.10) 
jehp(i) j 

Debido a que el conjunto {w°, wj,wj, . . . , w™} es monotono no decre- 
ciente, en el ambito de la planificacion en tiempo real se podra parar 
de iterar cuando se cumpla una de las dos siguientes condiciones: 

■ Si w^ 1 = wf, entonces ya se habra encontrado la solucion a la 
ecuacion, es decir, el valor de Ri. 

■ Si wf > D t , entonces no es necesario seguir iterando ya que el 
sistema no sera planificable respecto al proceso o tareapi, ya que 
su tiempo de respuesta es mayor que su deadline. 

Una vez alcanzado el punto en el que se ha discutido un modelo 
analitico para el calculo del tiempo de respuesta de un proceso, es im- 
portante recordar que un sistema de tiempo real es planificable si 

y solo si Vi e {1, 2, . . . , n}, Ri < D iy es decir, si los tiempos de respuesta 
de todos los procesos son menores o iguales a sus respectivos deadli- 
nes. Esta condicion es una condicion suficiente y necesaria para que 
el sistema sea planificable. Ademas, este modelo de analisis de tiempo 
real se puede completar, como se discutira mas adelante, siendo valido 
para computar el tiempo de respuesta. 

A continuacion se muestra un ejemplo de calculo del tiempo de 

respuesta para el conjunto de procesos cuyas caracteristicas se resu- 
men en la tabla 5.4. 
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Proceso 


T 


C 


P 


a 


80 


40 


1 


b 


40 


10 


2 


c 


20 


5 


3 



Tabla 5.4: Periodo (T), tiempo de ejecucion en el peor de los casos (C) y prioridad (P) de 
un conjunto de tres procesos para el calculo del tiempo de respuesta (R). 



El proceso de mayor prioridad, es decir, el proceso c, tendra un 
tiempo de respuesta R c igual a su tiempo de ejecucion C c , ya que no 
sufrira interrupcion alguna por otro proceso (el resto de procesos tie- 
nen menor prioridad) . 

Para el siguiente proceso de mayor prioridad, es decir, para el pro- 
ceso b, sera necesario realizar el calculo de su tiempo de respuesta R b 
utilizando la ecuacion 5.10: 

w% = C b + C c = 10 + 5 = 15 
A continuacion, se calcula w\ 

wi = c b + (r^i*c J o = io+rgi*5 = i5 

3 ehp(b) 3 

Debido a que w b = w\, no es necesario realizar otra iteracion. Por 
lo tanto, R b = 15 < D b = 40 (recuerda que en el modelo simple, T = D), 
siendo planificable dentro del sistema. 

El proceso a recibira interrupciones de b y de c al ser el proceso de 
menor prioridad. De nuevo, se repite el procedimiento, 

w° a = C a + C b + C c = 40 + 10 + 5 = 55 



wi = C a + ]T (r^l*C j )=40+rgl*10+r|l*5 = 40 + 20 + 15 = 75 

jehp(a) 3 

Debido a que w° a ^ w\, es necesario realizar otra iteracion: 

3 ehp{a) 3 

Finalmente 



3 ehp{a) 3 



75 75 

4o+r-i*io+r-i*5 



40 + 20 + 20 = 80 



80 80 
40 + ^ * 10 + ^20^ * 5 = 40 + 20 + 20 = 80 
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El tiempo de respuesta del proceso a cumple estrechamente su 
restriccion temporal ya que, en este caso, R a = D a . Sin embargo, el 
sistema es planificable ya que los tiempos de respuesta de todos los 
procesos son menores o iguales a sus deadlines. 

Es facil comprobar que el sistema es planificable dibujando el dia- 
grama de Gantt asociado al conjunto de procesos, tal y como muestra 
la figura 5.11. 




I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ► 

20 40 60 80 

Figura 5.11: Diagrama de Gantt para el conjunto de procesos de la tabla 5.4. 



5.4.3. Extendiendo el modelo simple de tareas 

En esta seccion se extiende el modelo simple planteado en la sec- 
cion 5.3.1, incluyendo aspectos relevantes como por ejemplo tareas 
esporadicas y la posibilidad de que un proceso bloquee a otro como 
consecuencia, por ejemplo, de la adquisicion de un recurso comparti- 
do. 

En primer lugar, se consideran procesos con un deadline inferior 
a su periodo (D < T) con el objetivo de manejar un modelo menos 
pesimista que el anterior. 

En segundo lugar, se considera la posibilidad de interaccion entre 
procesos, hecho que condiciona el calculo del tiempo de respuesta. 
Esta interaccion se plantea en terminos de un sistema concurrente 
de manera que un proceso de baja prioridad puede bloquear a otra 
tarea de alta prioridad debido a que utilice un recurso que esta ultima 
necesite durante un periodo de tiempo. Este tipo de situaciones se 
enmarcan en el concepto de inversion de prioridad y, aunque no se 
pueden evitar por completo, si que es posible mitigar su efecto. Por 
ejemplo, se puede plantear un esquema que limite el bloqueo y que 
este sea ponderable. 

Si se considera este nuevo factor para realizar el calculo del tiempo 
de respuesta de un proceso, entonces la ecuacion 5.5 se reformula de 
la siguiente forma: 

Ri = Ci + h + Bi (5.11) 

donde Bi es el maximo tiempo de bloqueo que puede sufrir el proceso 

Pi- 

Como ejemplo practice considere un sistema con cuatro procesos 
(a, b, c y d) cuyas prioridades han sido calculadas en base a un es- 
quema Deadline Monotonic Scheduling. El tiempo de activacion de las 
tareas, asi como su secuencia de ejecucion, son conocidos. Ademas, 
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los procesos comparten dos recursos R y S de una unica instancia 
(por ejemplo, dos impresoras), es decir, son recursos de acceso exclu- 
sivo. La tabla 5.5 muestra los datos de este ejemplo de inversion de 
prioridad. 



Proceso 


P 


Instante de activacion 


Secuencia de ejecucion 


a 


1 


0 


ERRRRE 


b 


2 


2 


EE 


c 


3 


2 


ESSE 


d 


4 


4 


EERSE 



Tabla 5.5: Atributos relevantes para un ejemplo de planificacion considerando inversion 
de prioridad (E, ciclo de ejecucion; R, ciclo de acceso al recurso R; S, ciclo de acceso al 
recurso S). 



En la figura 5. 12 se puede observar como se comporta el sistema 
en base a los atributos definidos en la tabla anterior. 



Inversion de prioridad 
del proceso d 



Tiempo de bloqueo de d 



HZ 



al 


aR 


cl 


cS 


dl 


d2 


cS 


c2 


bl 


b2 


aR 


aR 


aR 


dR 


dS 


d3 


a2 



I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — I — ► 

0 2 4 6 8 10 12 14 16 



Figura 5.12: Diagrama de Gantt para el ejemplo de inversion de prioridad para el con- 
junto de procesos de la tabla 5.5. 



A partir de la representacion grafica de la figura anterior, es sencillo 
obtener el tiempo de respuesta de los diferentes procesos del sistema: 
R a = 17, R b = 8, R c = 6 y R d — 12. En principio, era previsible esperar 
un tiempo de respuesta alto para el proceso de menor prioridad, es 
decir, para el proceso a, debido a que se ha utilizado un esquema 
apropiativo. Sin embargo, el tiempo de respuesta para el proceso de 
mayor prioridad, es decir, el proceso d, es excesivamente alto. La razon 
se debe a la inversion de prioridad que sufre en el ciclo 6 debido a 
la necesidad de utilizar un recurso (i?) adquirido anteriormente por 
el proceso a, ademas de emplear un esquema basado en prioridades 
puramente estaticas. 



El protocolo de herencia de prioridad 

Un posible mecanismo para mitigar la inversion por prioridad con- 
siste en utilizar la herencia de prioridad [4] . En esencia, este esquema 
se basa en que la prioridad de un proceso no sea estatica, sino que 
esta cambie cuando, por ejemplo, un proceso esta a la espera de la 
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ejecucion de una seccion critica por parte de otro proceso. Por ejem- 
plo, si un proceso pi esta suspendido esperando a que otro proceso p 2 
termine de acceder a un objeto protegido, entonces la prioridad de p 2 
obtiene el mismo valor (hereda) que la prioridad de pi , en caso de que 
fuera menor. 

Este planteamiento posibilita que el proceso que herede una prio- 
ridad alta tenga preferencia sobre otros procesos que, en caso de no 
utilizar este esquema, alargarian el tiempo de respuesta de la tarea 
cuya prioridad se hereda. En el ejemplo de la figura 5. 12, si el proceso 
a hubiese heredado la prioridad del proceso d al acceder al recurso R, 
entonces a tendria prioridad sobre bye, respectivamente. 



Para llevar a cabo un calculo del tiempo de bloqueo de un proce- 
so utilizando este esquema simple de herencia de prioridad se puede 
utilizar la siguiente formula [3] : 



donde R representa el numero de recursos o secciones criticas, mien- 
tras que utilizacion(r, i) = 1 si el recurso r se utiliza al menos por un 
proceso cuya prioridad es menor que la de p { y, al menos, por un pro- 
ceso con prioridad mayor o igual a pi. Si no es asi, utilizacion(r,i) = 0. 
Por otra parte, C r es el tiempo de ejecucion del recurso o seccion critica 
r en el peor caso posible. 

La figura 5.13 muestra las lineas temporales y los tiempos de res- 
puesta para el conjunto de procesos de la tabla 5.5 utilizando un es- 
quema simple en el que se refleja el problema de la inversion de prio- 
ridad y el protocolo de herencia de prioridad, respectivamente. 

En el caso del esquema simple, se puede apreciar de nuevo como 
el tiempo de respuesta del proceso d, el cual tiene la mayor prioridad, 
es de 17 unidades de tiempo, siendo el tiempo de respuesta mas alto 
de todos los procesos. El extremo opuesto esta representado, curiosa- 
mente, por el proceso de menor prioridad, es decir, el proceso a, cuyo 
tiempo de respuesta es el menor de todos (9 unidades de tiempo) . Una 
vez mas, se puede apreciar como el bloqueo del recurso S por parte del 
proceso a penaliza enormemente al proceso d. 



Cuando se utiliza un protocolo de herencia de prioridad, la prio- 
ridad de un proceso sera el maximo de su propia prioridad y las 
prioridades de otros procesos que dependan del mismo. 



R 




(5.12) 
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Proceso 



|e | E | 



| r I s | e ^ 



E 


S 




S 


E 













H h 



+ 



H 1- 



R =12 

d 

R=6 

C 

R b =8 
R=17 



+ 



-I ► 



0 

Proceso 



^ E | E | 



H h 



12 
(a) 



16 



20 



R I I 5 I E A 



E 


S 





S 






E 



V 9 

R=12 



=14 



H h 



4- 



| e I R a =17 

H 1 1 1- 



4 Instante de 
activacion 



12 
(b) 



16 



Enejecucion | J Desalojado 



20 



Instante de 
O finalizacion 



Figura 5.13: Lmeas de tiempo para el conjunto de procesos de la tabla 5.5 utilizando 
a) un esquema de priorldades fijas con aproplaclon y b) el protocolo de herencla de 
prlorldad. A la derecha de cada proceso se muestra el tiempo de respuesta asoclado. 
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En el caso del protocolo de herencia de prioridad, este problema se 
limita considerablemente. Observe como el proceso a hereda la priori- 
dad del proceso d cuando el primero adquiere el recurso R. Este plan- 
teamiento permite que a libere R tan pronto como sea posible para que 
d pueda continuar su ejecucion. 

De este modo, Rd se decrementa hasta las 9 unidades de tiempo, 
mientras que R a se mantiene en 17. El proceso de mayor prioridad ha 
finalizado antes que en el caso con inversion de prioridad. 

Desafortunadamente, R c y R b se han visto penalizados debido a la 
herencia de prioridad de a durante el tiempo de uso del recurso R. 

El tiempo de bloqueo asociado al protocolo de herencia de priori- 
dad se puede calcular facilmente para el ejemplo discutido mediante 
la ecuacion 5.12. Asi, es posible obtener los respectivos tiempos de 
bloqueo de los diferentes procesos: 

B a = 0 



B b = C aJi = 4 
B c = C a . R = 4 

B d = C c , s + C a .R = 2 + 3 = 5 

El protocolo de techo de prioridad inmediato 

El protocolo de herencia de prioridad garantiza un limite superior 
en relacion al numero de bloqueos que un proceso de alta prioridad 
puede sufrir. Sin embargo, este limite puede contribuir a que el calculo 
de tiempo de respuesta en el peor caso sea demasiado pesimista. Por 
ejemplo, en la seccion anterior se ha mostrado como el protocolo de 
herencia de prioridad genera una cadena de bloqueos que hace que el 
tiempo de respuesta de varios procesos se vea afectado negativamente. 

En este contexto, el gestor de recursos es el responsable de minimi- 
zar el bloqueo y eliminar las condiciones de fallo o interbloqueos. Los 
protocolos de acotacion de prioridad [11] permiten tratar con es- 
ta problematica. En esta seccion se discutira el protocolo de techo de 
prioridad inmediato, pero tambien se comentaran aspectos del proto- 
colo original de acotacion de prioridad. Estos dos protocolos de acota- 
cion comparten algunas caracteristicas (al ejecutarse en sistemas con 
una unica CPU) [3]: 

■ Un proceso de prioridad alta solo puede ser bloqueado una vez 
por procesos de prioridad inferior. 

■ Los interbloqueos se previenen. 

■ Los bloqueos transitivos se previenen. 
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■ El acceso exclusivo a los recursos esta asegurado. 

Basicamente, los protocolos de acotacion de prioridad garantizan 
que si un recurso esta siendo bloqueado por un determinado proceso 
Pi , y esta situacion conduce a que otro proceso p 2 con mayor prioridad 
se bloquee, entonces no se permite que ningun otro recurso que pueda 
bloquear a p 2 sea bloqueado mas que por p\ . 



En el caso particular del protocolo de techo de prioridad inme- 

diato es importante considerar las siguientes propiedades [3] : 

■ Cada proceso pi tiene asignada una prioridad P l por defecto (por 
ejemplo, utilizando un esquema DMS). 

■ Cada recurso i\ tiene asociado un valor cota estatico o techo de 
prioridad TP t , que representa la prioridad maxima de los proce- 
sos que hacen uso del mismo. 

■ Cada proceso pi puede tener una prioridad dinamica, que es el 
valor maximo entre su propia prioridad estatica y los techos de 
prioridad de los recursos que tenga bloqueados. 

En esencia, el protocolo de techo de prioridad inmediato consiste 
en que un proceso solo puede hacer uso de un recurso si su prioridad 
dinamica es mayor que el techo de todos los recursos que estan siendo 
usados por otros procesos. Por ejemplo, si un proceso pi utiliza un 
recurso r\ con techo de prioridad Q y otro proceso p 2 con prioridad P 2 , 
P 2 < Q, quiere usar otro recurso r 2 , entonces el proceso p 2 tambien se 
bloquea. 

La duracion maxima de un bloqueo viene determinada por la si- 
guiente ecuacion: 



El tiempo de bloqueo Bi de un proceso pi viene determinado por el 
maximo tiempo de uso de un recurso por parte de un proceso, conside- 
rando el conjunto de procesos con menor prioridad que Pi accediendo 
a recursos con un techo de prioridad igual o mayor a Pi . 

El planteamiento del protocolo de techo de prioridad inmediato tie- 
ne ciertas consecuencias: 

■ Cada proceso se bloquea como maximo en una ocasion. 



o 



En los protocolos de acotacion de prioridad, la ejecucion de un 
proceso se puede posponer incluso cuando el bloqueo de un 
recurso puede desencadenar un bloqueo multiple de procesos 
de mayor prioridad. 



Bi = max{Cj.k}, j G lp{i), k € hc{i) 



(5.13) 
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Proceso 
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E 


R 


S 


E 















R d =6 



R=12 

C 
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R=17 



+ 



A Instante de 
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12 



16 



20 
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ecucion 
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J ^ rmalizacion 



Figura 5.14: Linea de tiempo para el conjunto de procesos de la tabla 5.5 utilizando el 
protocolo de techo de prioridad inmedlato. 



■ No existen cadenas de bloqueos ni interbloqueos. 

■ Cuando una tarea adquiere un recurso, entonces hereda su techo 
de prioridad mientras lo utilice. 

La figura 5. 14 muestra la linea de tiempo del conjunto de procesos 
de la tabla 5.5. 

En primer lugar, es necesario calcular el techo de prioridad de los 
recursos R y S, considerando el maximo de las prioridades de los pro- 
cesos que hacen uso de ellos: 

TP R = max{P a , P d } = max{l, 4} = 4 

TP S = max{P c , P d } = max{3, 4} = 4 

En el instante de tiempo 1, el proceso a actualiza su prioridad dina- 
mica a 4, es decir, utilizando el valor del techo de prioridad del recurso 
R. Por ello, y aun cuando en los instantes de tiempo 2 y 4, respectiva- 
mente, se activan el resto de procesos, el proceso a no es desalojado. 

Es importante considerar cuando se produce la reduccion efectiva 
de la prioridad dinamica de un proceso. Por ejemplo, el proceso a re- 
tornara a su prioridad por dejecto justo despues de liberar el recurso 
R, es decir, en el instante de tiempo 5. 

Por otra parte, el tiempo de respuesta de los procesos es identico al 
calculado cuando se utiliza el protocolo de herencia de prioridad, salvo 
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por el proceso d, el cual tiene la mayor prioridad. En este caso, dicho 
proceso ha reducido su tiempo de respuesta en un 33 %, pasando de 9 
unldades de tiempo a 6. 

Ejercicio practico 1. Protocolo de herencia de prioridad 

En este apartado se plantea un problema de planificacion concreto 
en el que se aplica el protocolo de herencia de prioridad y se calculan 
tiempos de bloqueo, interferencia y respuesta. 

Considere un sistema de tiempo real compuesto de cuatro tareas 
criticas cuyas caracteristicas se muestran resumidas en la tab la 5.6. 
El metodo de planificacion esta basado en prioridades fijas con desalo- 
jo en base a un esquema Deadline Monotonic Scheduling. El acceso a 
los recursos se realiza mediante el protocolo de herencia de prioridad. 



Tarea 


T 


C 


D 


r\ 




^3 




a 


80 


10 


80 


3 






5 


b 


150 


20 


150 


2 


2 


1 




c 


100 


10 


15 


1 


1 






d 


500 


12 


30 


2 




4 





Tabla 5.6: Periodo (T), tiempo de ejecucion en el peor de los casos (C), deadline, y tiempo 
de uso de los recursos r1.r2.r3y rs, para un conjunto de cuatro procesos. 

Calcule las prioridades y el tiempo de bloqueo de las tareas. Obtenga 
el tiempo de respuesta de la tarea a. 

En primer lugar, se procede a realizar el calculo de las prioridades 

de las tareas en base a un esquema DMS, es decir, asignando una 
mayor prioridad a aquellas tareas cuyo deadline sea menor. Asi, 

P a = 2,P b = l,P c = 4,P d = 3 

En segundo lugar, el tiempo de bloqueo se obtiene haciendo uso 
de la ecuacion 5. 12. Asi, 

B b = Q 

B a = Cb, ri + Cfc,r 2 + Cb,r 3 = 2 + 2+1 = 5 
Bd = Cb, ri + Ca,n + Cb^ r2 + Cb,r 3 = 2 + 3 + 2 + 1 = 8 

B c = Cb t n + Ca,n + Cd,n + C&,r 2 = 2 + 3 + 2 + 2 = 9 

Recuerde que para contabilizar el tiempo de uso de un recurso r; 
por parte de una tarea p it dicho recurso ha de usarse al menos por 
una tarea con menor prioridad que P l y al menos por una tarea con 
prioridad mayor o igual a P l . 
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Finalmente, para calcular el tiempo de respuesta de la tarea a 
es necesario hacer uso de la ecuacion 5.11 (conslderando no solo el 
tiempo de bloqueo sino tambien el de interferencia /,) e iterando 
segun la ecuacion 5.10. Asi, 



w a = C a + B a + I a = C a + B a + C c + C d = 10 + 5 + 10 + 12 = 37 
wl = C a + B a + I a = C a + B a + A * C c + A * C d = 

±c J-d 

37 37 
10 + 5 + [ 100 ] * 10 + [ 50 ] * 12 = 37 

Debido a que w a = w\, entonces R a = w 1 a = 37. 

Ejercicio practico 2. Techo de prioridad inmediato 

En este apartado se plantea un problema de planificacion concreto 
en el que se aplica el protocolo de techo de prioridad inmediato y se 
calculan tiempos de bloqueo, interferencia y respuesta. 

Considere un sistema de tiempo real compuesto de cuatro tareas 
criticas cuyas caracteristicas se muestran resumidas en la tabla 5.7. 
El metodo de planificacion esta basado en prioridades fijas con des- 
alojo y un esquema Deadline Monotonic Scheduling. El acceso a los 
recursos se realiza mediante el protocolo de techo de prioridad inme- 
diato. 



Tarea 


T 


c 


D 


n 


r-i 


^3 




a 


100 


20 


100 


3 






5 


b 


200 


20 


200 


2 


2 






c 


100 


5 


15 


1 








d 


50 


12 


20 


2 




4 





Tabla 5.7: Periodo (T), tiempo de ejecucion en el peor de los casos (C), deadline, y tiempo 
de uso de los recursos n, r 2 , r 3 y r 4 para un conjunto de cuatro procesos. 



Calcule las prioridades de las tareas y el techo de prioridad de los 
recursos. Obtenga el tiempo de bloqueo de las tareas y discuta si el 
sistema es planificable o no. 

En primer lugar, se procede a realizar el calculo de las prioridades 

de las tareas, considerando que la tarea con un menor deadline tiene 
una mayor prioridad. De este modo, 

P a = 2,P b = l,P c = 4,P d = 3 

A continuacion se obtiene el techo de prioridad de los recursos. Re- 
cuerde que el techo de prioridad de un recurso es la prioridad maxima 
de las tareas que hacen uso del mismo. Asi, 
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TP ri = max{P a ,P b , P c , P d } = max{2, 1, 4, 3} = 4 
TP r2 = max{Pb} = max{l} = 1 
TP r3 — max{P d } = max{i\ = 3 

TP ri — max{P a } = max{A\ = 4 

En segundo lugar, el tiempo de bloqueo se obtiene haciendo uso 
de la ecuacion 5.13. Recuerde que dicho valor, cuando se aplica el 
protocolo de techo de prioridad inmediato, viene determinado por el 
maximo tiempo de uso de un recurso por parte un proceso, conside- 
rando el conjunto de procesos con menor prioridad que P, accediendo 
a recursos con un techo de prioridad igual o mayor a Pj. Asi, 

B d = max{C atri , C a ,r 3 , Cb, ri , Cb t r 3 } = max{3, -, 2, -} = 3 

A la hora de calcular B d , Note como en la tabla 5.8 se resaltan los 
dos procesos (a y b) que cumplen la anterior restriccion. Por lo tanto, 
habria que obtener el maximo de utilizacion de dichos procesos con 
respecto a los recursos que tienen un techo mayor o igual que P d , tal 
y como muestra la tabla 5.9. 



Tarea 


T 


c 


D 


n 


T2 


^3 


r-4 


a 


100 


20 


100 


3 






5 


b 


200 


20 


200 


2 


2 






c 


100 


5 


15 


1 








d 


50 


12 


20 


2 




4 





Tabla 5.8: Obteniendo 6^ (tiempo de bloqueo de la tarea d). Las tareas ay d son las que 
tienen menor prioridad que d (linicas que pueden bloquearla) . 



Tarea 


T 


c 


D 




T2 




a 


100 


20 


100 


3 






5 


b 


200 


20 


200 


2 


2 






c 


100 


5 


15 


1 








d 


50 


12 


20 


2 




4 





Tabla 5.9: Obteniendo fe^ (tiempo de bloqueo de la tarea d). Los recursos n y r-j, tiene 
un techo de prioridad mayor o igual que la prioridad de d (las tareas de menos prioridad 
solo pueden bloquear a d si acceden a estos recursos) . 
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El resto de tiempos de bloqueo son los siguientes: 

B a = max{Cb, ri } = max{2} = 2 

Bb = max{0} = 0 

B c = max{C a . ri , C biri , C diri } = max{3, 3, 2} = 3 

Finalmente, para determinar si el sistema es planificable o no es 

necesario calcular el tiempo de respuesta de todas las tareas, haciendo 
uso de la ecuacion 5.11 (considerando no solo el tiempo de bloqueo B t 
sino tambien el de interferencia e iterando segun la ecuacion 5.10. 
Para cada tarea p { , habra que comprobar si su tiempo de respuesta R4 
es menor o igual a su deadline Di. Asi, 

R C = C C + B C + I C = 5 + 3 + 0 = 8 

debido a que p c es la tarea de mayor prioridad y, por lo tanto, no recibe 
interferencias de otras tareas. Note que R c < D c (8 < 20). 

Rd = Cd + B d + I d 
w° d = C d + B d + C c = 12 + 3 + 5 = 20 

w° 20 
w d = C d + B d + f^l * C c = 12 + 3 + \— 1 * 5 = 12 + 3 + 5 = 20 

Debido a que w n d = w\, entonces R d = w d = 20. Note que R d < D d 
(20 < 20). 

R a = C a + B a + I a 
w° a = C a + B a + C d + C c = 20 + 2 + 12 + 5 = 31 



wi = c a + B a + r^i * c d + A * c c = 

12 + 3 + & * 12 + f^rl * 5 = 20 + 2 + 12 + 5 = 31 

OvJ 1UU 

Debido a que w° =ioJ, entonces i? a = = 31. Note que R a < D a 
(31 < 100). 
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Finalmente, 



Rb = Cb + B b + I b 



w% = C b + B b + C d + C c + C a = 20 + 0 + 20 + 12 + 5 = 57 



Cb + Bb 



1 a 



57 57 57 

20 + o + r— i * 12 + r — i * 5 + r — i * 20 = 

1 50 1 1 100 1 1 100 1 

20 + 0 + 24 + 5 + 20 = 69 



Como wl 7^ w\, es necesario seguir iterando. 



w h 



Cb + Bh 



\^VC d 



1 T r 



m*c a 

J- a 



r 69 n r 69 n r 69 

2 o+o + r 50 i*i2 + r 100 i*5 + r 100 i*2o= 

20 + 0 + 24 + 5 + 20 = 69 



Debido a que = to^, entonces R b = w 2 a = 69. Note que i? b < D b 
(69 < 200). 

Una vez obtenidos todos los tiempos de respuesta de todos los pro- 
cesos y comparados estos con los respectivos deadline, se puede afir- 
mar que el sistema critico es planificable 



5.4.4. Consideraciones finales 

El modelo simple de tareas discutido en este capitulo se puede ex- 
tender aun mas considerando otros aspectos con el objetivo de llevar 
a cabo un analisis mas exhaustivo del tiempo de respuesta. Por ejem- 
plo, seria posible considerar aspectos que tienen una cierta influencia 
en la planificacion de un sistema de tiempo real, como por ejemplo el 
jitter o variabilidad temporal en el envio de senales digitales, los cam- 
bios de contexto, el tiempo empleado por el planificador para decidir 
cual sera el siguiente proceso o tarea a ejecutar, las interrupciones, 
etc. 

Por otra parte, en el ambito de los sistemas de tiempo real no 

criticos se pueden utilizar otras alternativas de planificacion menos 
pesimistas y mas flexibles, basadas en una variacion mas dinamica 
de las prioridades de los procesos y considerando especialmente la 
productividad del sistema. 

En [3] se contemplan algunas de estas consideraciones y se rea- 
liza un analisis mas exhaustivo de ciertos aspectos discutidos en el 
presente capitulo. 



El pue 




Figura A. 1: Esquema grafico 
del problema del puente de 
un solo carrll. 



A.l. Enunciado 



Suponga un puente que tiene una carretera con un unico carril 
por el que los coches pueden circular en un sentido o en otro. La 
anchura del carril hace imposible que dos coches puedan pasar de 
manera simultanea por el puente. El protocolo utilizado para atravesar 
el puente es el siguiente: 

■ Si no hay ningun coche circulando por el puente, entonces el 
primer coche en llegar cruzara el puente. 

■ Si un coche esta atravesando el puente de norte a sur, enton- 
ces los coches que esten en el extremo norte del puente tendran 
prioridad sobre los que vayan a cruzarlo desde el extremo sur. 

■ Del mismo modo, si un coche se encuentra cruzando de sur a 
norte, entonces los coches del extremo sur tendran prioridad so- 
bre los del norte. 
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A. 2. Codigo fuente 



Listado A. 1: Makefile para la compilacion automatica 



DIROBJ := obj/ 
DIREXE := exec/ 
DIRHEA := include/ 
DIRSRC := src/ 

5 

6 CFLAGS := -1$ (DIRHEA) -c -Wall 

LDLIBS := -lpthread -lrt 
8 CC : = gcc 

9 

all : dirs manager coche 

11 

dirs : 

13 mkdir -p $ (DIROBJ) $ (DIREXE) 

14 

15 manager: $ (DIROBJ) manager . o $ (DIROBJ) semaforol . o $ (DIROBJ) memorial . 

o 

16 $(CC) -o $ (DIREXE) $@ $ A $ (LDLIBS) 
17 

coche: $ (DIROBJ) coche . o $ (DIROBJ) semaforol . o $ (DIROBJ) memorial . o 
19 $(CC) -o $ (DIREXE) $@ $" $ (LDLIBS) 

20 

21 $ (DIROBJ) %.o : $(DIRSRC)%.c 

22 $(CC) $ (CFLAGS ) $" -o $@ 

23 

clean : 

rm -rf *~ core $ (DIROBJ) $ (DIREXE) $ (DIRHEA) *~ $ (DIRSRC) *~ 



Listado A.2: Archivo semaforol. h 



#ifndef SEMAF0R0I_H 

#define SEMAFOROI_H 

#include <semaphore . h> 
4 // Crea un semaforo POSIX. 

sem_t *crear_sem (const char *name, unsigned int valor) ; 
6 // Obtiene un semaforo POSIX (ya existente) . 

sem_t *get_sem (const char *name) ; 
8 // Cierra un semaforo POSIX. 

void destruir_sem (const char *name) ; 
10 // Incrementa el semaforo. 

void signal_sem (sem_t *sem) ; 

12 // Decrementa el semaforo. 

13 void wait_sem (sem_t *sem) ; 
#endif 



A. 2. Codigo fuente 
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Listado A.3: Archivo semaforol.c 



1 #include <stdio.h> 

2 #include <errno.h> 
finclude <stdlib.h> 
finclude <unistd.h> 

5 #include <fcntl.h> 

#include <semaf orol . h> 

7 

sem_t *crear_sem (const char *name, unsigned int valor) { 



sem_t *sem; 

sem = sem_open (name, 0_CREAT, 0644, valor); 
11 if (sem == SEM_FAILED) { 

fprintf (stderr, "Error al crear el sem.: %s\n", 

13 strerror (errno) ) ; 

14 exit (1) ; 
) 

return sem; 



17 } 
18 

sem_t *get_sem (const char *name) { 



2C sem_t *sem; 

21 sem = sem_open (name, 0_RDWR) ; 

22 if (sem == SEM_FAILED) { 

fprintf (stderr, "Error al obtener el sem. : %s\n", 

24 strerror (errno) ) ; 

25 exit(l); 
} 

return sem; 



28 } 
29 

30 void destruir_sem (const char *name) { 



sem_t *sem = get_sem (name) ; 
32 // Se cierra el sem. 

if ( (sem_close (sem) ) == -1) { 

fprintf (stderr, "Error al cerrar el sem.: %s\n", 

35 strerror (errno) ) ; 

36 exit(l); 
v ) 

38 // Se elimina el sem. 

39 if ( (sem_unlink (name) ) == -1) { 

fprintf ( stderr , "Error al destruir el sem. : %s\n", 

41 strerror (errno) ) ; 

42 exit(l); 
) 



44 } 
45 

46 void signal_sem (sem_t *sem) { 



47 if ( (sem_post (sem) ) == -1) { 

fprintf (stderr, "Error al modificar el sem.: %s\n", 

49 strerror (errno) ) ; 

50 exit (1) ; 
) 



52 } 
53 

54 void wait_sem (sem_t *sem) { 



55 if ( (sem_wait (sem) ) == -1) { 

fprintf (stderr, "Error al modificar el sem.: %s\n", 

57 strerror (errno) ) ; 

58 exit (1) ; 
} 



60 } 
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Listado A.4: Archivo memorial. h 



#ifndef VARIABLE I_H 

#define VARIABLEI_H 

3 // Crea un objeto de memoria compartida . 

4 // Devuelve el descriptor de archivo. 

int crear_var (const char *name, int valor) ; 
6 // Obtiene el descriptor asociado a la variable. 

int obtener_var (const char *name) ; 
8 // Destruye el objeto de memoria compartida. 

void destruir_var (const char *name) ; 

10 // Modifica el valor del objeto de memoria compartida. 

11 void modif icar_var (int shm_fd, int valor) ; 

12 // Devuelve el valor del objeto de memoria compartida. 

13 void consultar_var (int shm_fd, int *valor) ; 
#endif 



Listado A. 5: Archivo memorial. c (1 de 2) 



i 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 

34 
35 

36 
37 
38 
39 
40 
41 
42 
43 



#include <stdio.h> 
#include <errno.h> 
#include <string.h> 
#include <stdlib.h> 
#include <unistd.h> 
#include <fcntl.h> 
finclude <sys/mman.h> 
#include <sys/stat.h> 
#include <sys /types . h> 

finclude <memoriaI.h> 

int crear_var (const char 
int shm_fd; 
int *p; 



*narae, int valor) { 



// Abre el objeto de memoria compartida. 

shm_fd = shm_open (name, 0_CREAT | 0_RDWR, 0666); 

if (shm_fd == -1) { 

fprintf (stderr, "Error al crear la variable: %s\n" 
strerror (errno) ) ; 

exit (1) ; 



// Establecer el tamafio. 

if ( f truncate (shm_fd, sizeof(int)) == -1) { 

fprintf ( stderr , "Error al truncar la variable: 

strerror (errno) ) ; 
exit (1) ; 



%s \ n " 



// Mapeo del objeto de memoria compartida. 

p = mmap(NULL, sizeof(int), PR0T_READ | PROT_WRITE, MAP_SHARED, 

shm_fd, 0) ; 
if (p == MAP_FAILED) { 

fprintf ( stderr , "Error al mapear la variable: %s\n", strerror ( 

errno) ) ; 
exit (1) ; 



*p = valor; 

munmap(p, sizeof (int) ) ; 



return shm_fd; 



A.2. Codigo fuente 
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44 

int obtener_var (const char *name) { 

46 int shm_fd; 
47 

48 // Abre el objeto de memoria compartida. 

49 shm_fd = shm_open (name, 0_RDWR, 0666); 

50 if (shm_fd == -1) { 

fprintf (stderr, "Error al obtener la variable: %s\n", strerror ( 
errno) ) ; 
52 exit(l); 
5 ! 1 
54 

55 return shm_fd; 

56 } 
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Listado A.6: Archivo memorial. c (2 de 2) 



i 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 



/* includes previos. . . */ 
#include <memoriaI.h> 

void clestruir_var (const char *name) { 
int shm_fd = obtener_var (name) ; 

if (close (shm_fd) == -1) { 

f printf ( stderr , "Error al destruir la variable: %s\n" 

strerror (errno) ) ; 
exit (1) ; 



if (shm_unlink (name) == -1) { 

f printf ( stderr , "Error al destruir la variable: %s\n" 

strerror (errno) ) ; 
exit (1) ; 



void modif icar_var (int shm_fd, int valor) { 
int *p; 

// Mapeo del objeto de memoria compartida. 

p = mmap(NULL, sizeof(int), PR0T_READ | PROT_WRITE, 

MAP_SHARED, shm_fd, 0); 
if (p == MAP_FAILED) { 

fprintf (stderr, "Error al mapear la variable: %s\n" 

strerror (errno) ) ; 
exit (1) ; 



*p = valor; 

munmap(p, sizeof (int) ) ; 



void consultar_var (int shm_fd, int *valor) { 
int *p, valor; 

// Mapeo del objeto de memoria compartida. 

p = mmap(NULL, sizeof (int), PROT_READ | PROT_WRITE, 

MAP_SHARED, shm_fd, 0); 
if (p == MAP_FAILED) { 

fprintf (stderr, "Error al mapear la variable: %s\n" 

strerror (errno) ) ; 
exit (1) ; 



*valor = *p; 

munmap (p, sizeof (int)' 



A. 2. Codigo fuente 
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Listado A.7: Proceso manager 



1 #include <stdio.h> 
finclude <string.h> 
finclude <stdlib.h> 
finclude <unistd.h> 
finclude <signal.h> 
finclude <sys/wait.h> 
finclude <memoriaI.h> 
finclude <semaf orol . h> 

9 

10 fdefine COCHES 30 

11 fdefine MAX_T_LANZAR 3 
fdefine PUENTE "puente" 
fdefine MUTEXN "mutex_n" 
fdefine MUTEXS "mutex_s" 

15 fdefine COCHESNORTE " coches_norte " 
fdefine COCHESSUR "coches_sur" 

17 

L8 pid_t pids [COCHES] ; 

19 void liberarecur sos (); void f inalizarprocesos (); 

20 void controlador (int senhal) ; 
21 

22 int main (int argc, char *argv[] ) { 

23 pid_t pid_hijo; int i; 
24 

srand ( (int) getpid ( ) ) ; 

26 // Creacion de semaforos y segmentos de memoria compartida. 

27 crear_sem (PUENTE, 1); crear_sem (MUTEXN, 1); crear_sem (MUTEXS, 1); 

28 crear_var (COCHESNORTE, 0); crear_var (COCHESSUR, 0 ) ; 
29 

30 // Mane jo de Ctrol+C. 

31 if (signal (SIGINT, controlador) == SIG_ERR) 

fprintf (stderr, "Abrupt termination . \n" ) ; 

S3 ) 
34 

for (i = 0; i < COCHES; i++) { // Se lanzan los coches . . . 
switch (pid_hijo = fork()) { 
case 0 : 

38 if ((i % 2) == 0) // Coche Norte. 

execl (" . /exec/coche", "coche", "N", PUENTE, MUTEXN, COCHESNORTE 
, NULL) ; 

40 else // Coche Sur. 

execl (". /exec/coche", "coche", "S", PUENTE, MUTEXS, COCHESSUR, 
NULL) ; 

42 break; 

43 }// Fin switch. 

44 sleep (rand () % MAX_T_LANZAR) ; 

45 }// Fin for. 
46 

47 for (i = 0; i < COCHES; i++) waitpid (pids [ i ] , 0, 0); 

48 liberarecursos ( ) ; return EXIT_SUCCESS; 

49 } 
50 

51 void liberarecursos () { 

52 destruir_sem (PUENTE) ; destruir_sem (MUTEXN) ; destruir_sem (MUTEXS ) ; 

53 destruir_var (COCHESNORTE) ; destruir_var (COCHESSUR) ; 

54 } 

55 

56 void f inalizarprocesos () { 

57 int i; printf ("\n Finalizando procesos \n"); 

58 for (i = 0; i < COCHES; i++) 

59 if (pids[i]) { 

printf ("Finalizando proceso [ %d] . . . ", pids[i]); 
kill (pids [i] , SIGINT); printf ("<Ok>\n"); 

62 } 



( 

exit (EXIT_FAILURE) ; 
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63 } 
64 

65 void controlador (int senhal) { 

66 f inalizarprocesos ( ) ; liberarecur sos ( ) ; 

67 printf ("\nFin del programa (Ctrol + C)\n"); exit (EXIT_SUCCESS) ; 

68 } 



A. 2. Codigo fuente 
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Listado A.8: Proceso coche 



#include <sys/types . h> 
finclude <unistd.h> 
finclude <stdlib.h> 
4 (finclude <stdio.h> 
finclude <string.h> 
finclude <semaf orol . h> 
finclude <memoriaI . h> 
fdefine MAX_TIME_CRUZAR 5 

9 

10 void coche ( ) ; void cruzar (); 
11 

12 int main (int argc, char *argv[] ) { 

13 coche (argv [ 1 ] , argv[2], argv[3], argv[4]); 
return 0 ; 

15 } 
16 

17 /* salida permite identificar el origen del coche (N o S) */ 

18 void coche (char *salida, char *id_puente, 

19 char *id_mutex, char *id_num_coches) { 

20 int num_coches_handle, valor; 

21 sem_t *puente, *mutex; 
22 

23 srand ( (int) getpid ( ) ) ; 
24 

25 puente = get_sem (id_puente) ; 

26 mutex = get_sem ( id_mutex) ; 
num_coches_handle = obtener_var ( id_num_coches ) ; 

28 

29 /* Acceso a la variable compartida 'num coches' */ 

30 wait_sem (mutex) ; 
31 

32 consultar_var (num_coches_handle, &valor) ; 

33 modif icar_var (num_coches_handle, ++valor) ; 

34 /* Primer coche que intenta cruzar desde su extremo */ 

35 if (valor == 1) 

wait_sem (puente ) ; /* Espera el acceso al puente */ 

37 

38 signal_sem (mutex) ; 
39 

40 cruzar (salida) ; /* Tardara un tiempo aleatorio */ 
41 

42 wait_sem (mutex) ; 
43 

44 consultar_var (num_coches_handle, &valor) ; 

45 modif icar_var (num_coches_handle, — valor); 

46 /* Ultimo coche en cruzar desde su extremo */ 

47 if (valor == 0) 

signal_sem (puente ) ; /* Libera el puente */ 

49 

50 signal_sem (mutex) ; 

51 } 
52 

53 void cruzar (char *salida) { 

54 if (strcmp (salida, "N") == 0) 

printf("%d cruzando de N a S.. 

56 else 

57 printf (" %d cruzando de S a N. . 

58 sleep(rand() % MAX_TIME_CRUZAR + 

59 } 



. \n" , getpid ( ) ) ; 

. \n" , getpid ( ) ) ; 
1) ; 





B.l. Enunciado 



Los filosofos se encuentran comiendo o pensando. Todos compar- 
ten una mesa redonda con cinco sillas, una para cada filosofo. En el 
centra de la mesa hay una fuente de arroz y en la mesa solo hay cinco 
palillos, de manera que cada filosofo tiene un palillo a su izquierda y 
otro a su derecha. 

Cuando un filosofo piensa, entonces se abstrae del mundo y no se 
relaciona con ningun otro filosofo. Cuando tiene hambre, entonces in- 
tenta acceder a los palillos que tiene a su izquierda y a su derecha 
(necesita ambos). Naturalmente, un filosofo no puede quitarle un pali- 
llo a otro filosofo y solo puede comer cuando ha cogido los dos palillos. 
Cuando un filosofo termina de comer, deja los palillos y se pone a 
pensar. 



Figura B.l: Esquema grafi- 
co del problema original de 
los filosofos comensales (di- 
ning philosophers). 
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B.2. Codigo fuente 



Listado B.l: Makefile para la compilacion automatica 



DIROBJ := obj/ 
DIREXE := exec/ 
DIRSRC := src/ 

4 

CFLAGS := -c -Wall 
LDLIBS := -lrt 
CC := gcc 

8 

all : dirs manager filosofo 

10 

dirs: 

mkdir -p $ (DIROBJ) $ (DIREXE) 

13 

14 manager: $ (DIROBJ) manager . o 

$(CC) -o $ (DIREXE) $@ $" $ (LDLIBS) 

16 

17 filosofo: $ (DIROBJ) filosofo . o 

$(CC) -o $ (DIREXE) $@ $ A $ (LDLIBS) 

19 

20 $ (DIROBJ) %.o : $(DIRSRC)%.c 

21 $(CC) $ (CFLAGS) $" -o $@ 

22 

clean : 

rm -rf *~ core $ (DIROBJ) $ (DIREXE) $ (DIRSRC) *~ 
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Listado B.2: Archivo manager.c 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 



#include 
#include 
finclude 
#include 
#include 
finclude 
finclude 
finclude 
finclude 
finclude 



<unistd.h> 
<signal . h> 
<str ing . h> 
<stdlib .h> 
<stdio.h> 
<signal . h> 
<wait . h> 
<sys/types . h> 
<sys/ stat . h> 
<mqueue . h> 



f define BUZON_MESA " /buzon_mesa" 

f define BUZ0N_PALILL0 " /buzon_palillo_ 

fdefine FIL0S0F0S 5 

pid_t pids [FIL0S0F0S] ; 
mqd_t qHandlerMesa; 

mqd_t qHandlerPalillos [FILOSOFOS] ; 

void controlador (int senhal) ; 
void liberarecur SOS (); 
void f inalizarprocesos (); 

int main (int argc, char *argv[]) { 
int i ; 

struct mq_attr mqAttr; 
char buffer [64], caux[30], 
char buzon_palillo_i zq [ 30 ] 



/* Offset! 



f ilosof o [ 1 ] ; 
buzon_palillo_der [ 30 ] ; 



// Reseteo del vector de pids. 
memset (pids, 0, sizeof (pid_t ) 

// Atributos del buzon mesa. 
mqAttr .mq_maxmsg = (FILOSOFOS - 



* (FILOSOFOS)). 



1); mqAttr .mq_msgsize = 64; 



// Retrollamada de f inalizacion . 

if (signal (SIGINT, controlador) == SIG_ERR) { 

fprintf (stderr, "Abrupt termination . \n" ) ; 

exit (EXIT_FAILURE ) ; 

} 

// Creacion de buzones. . . 

qHandlerMesa = mq_open (BUZON_MESA, 0_WRONLY | 0_CREAT, 

S_IWUSR I S_IRUSR, SmqAttr) ; 
for (i = 0; i < (FILOSOFOS - 1); i++) 
// Para evitar el interbloqueo . . . 

// Solo 4 f ilosof os (maximo) intentan acceder a los palillos. 
mq_send (qHandlerMesa, buffer, sizeof (buffer) , 1); 

// Para los buzones de los palillos. 
mqAttr . mq_maxmsg = 1; 

// Un buzon por palillo. . . 

for (i =0; i < FILOSOFOS; i++) { 

sprintf (caux, "%s%d", BUZON_PALILLO, i); 

qHandlerPalillos [i] = mq_open (caux, 0_WR0NLY | 0_CREAT, 
S_IWUSR I S_IRUSR, SmqAttr) ; 

// Palillo inicialmente libre . 

mq_send (qHandlerPalillos [i] , buffer, sizeof (buff er) , 0); 

} 

// Lanzamiento de procesos f ilosof o. 
for (i = 0; i < FILOSOFOS ; i++) 
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65 if <(pids[i] = fork()) == 0) { 

sprintf (f ilosof o, "%d", i); 

sprintf (buzon_palillo_izq, "%s%d", BUZON_PALILLO, i); 
sprintf (buzon_palillo_der , "%s%d", 

BUZON_PALILLO, (i + 1) % FILOSOFOS); 
execl (". /exec/f ilosof o" , "filosofo", filosofo, BUZON_MESA, 
buzon_palillo_izq, buzon_palillo_der , NULL) ; 

72 } 
73 

74 for (i = 0; i < FILOSOFOS; i++) waitpid (pids [ i ] , 0, 0); 

75 f inalizarprocesos ( ) ; liberarecur sos ( ) ; 

76 printf ("\n Fin del programa\n" ) ; 
return 0 ; 

78 } 
79 

void controlador (int senhal) { 

81 f inalizarprocesos () ; liberarecur sos () ; 

82 printf ("\n Fin del programa (Control + C)\n"); 

83 exit (EXIT_SUCCESS) ; 

84 } 
85 

86 void liberarecursos () { 

87 int i; char caux [30]; 
88 

89 printf ("\n Liberando buzones . . . \n"); 

90 mq_close (qHandlerMesa) ; mq_unlink (BUZON_MESA) ; 
91 

for (i = 0; i < FILOSOFOS; i++) { 
93 sprintf (caux, "%s%d", BUZON_PALILLO, i) ; 

mq_close (qHandlerPalillos [ i ] ) ; mq_unlink (caux) ; 

95 } 

96 } 
97 

98 void f inalizarprocesos () { 

99 int i; 

100 printf (" Terminando \n"); 

101 for (i = 0; i < FILOSOFOS; i++) { 

102 if (pids[i]) { 

printf ( "Finalizando proceso [ %d] . . . ", pids[i]); 
kill (pids [i] , SIGINT) ; printf ("<0k>\n"); 

105 } 

106 } 

107 } 
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Listado B.3: Archivo filosofo.c 



finclude <unistd.h> 
finclude <signal.h> 
finclude <stdlib.h> 
4 (finclude <stdio.h> 
finclude <signal.h> 
finclude <mqueue.h> 
fdefine MAX_TIME_PENSAR 7 
fdefine MAX_TIME_COMER 5 

9 

10 void filosofo (char *filosofo, char *buzon_mesa, 



char *buzon_palillo_izq, char *buzon_palillo_der ) ; 
12 void controlador (int senhal) ; 

13 

14 int main (int argc, char *argv[]) { 

15 f ilosof o (argv [ 1 ] , argv[2], argv[3], argv[4]); 
return 0 ; 

17 } 
18 

19 void filosofo (char *filosofo, char *buzon_mesa, 

char *buzon_palillo_izq, char *buzon_palillo_der ) { 

21 mqd_t qHandlerMesa, qHandlerlzq, qHandlerDer; 

22 int n_filosofo; 

23 char buffer [64]; 
24 

25 // Retrollamada de f inalizacion . 

26 if (signal (SIGINT, controlador) == SIG_ERR) { 

fprintf (stderr, "Abrupt termination . \n" ) ; exit (EXIT_FAILURE ) ; 

28 } 

29 n_filosofo = atoi (filosofo) ; 
30 

31 // Recupera buzones. 

32 qHandlerMesa = mq_open (buzon_mesa, 0_RDWR) ; 

33 qHandlerlzq = mq_open (buzon_palillo_izq, 0_RDWR) ; 

34 qHandlerDer = mq_open (buzon_palillo_der , 0_RDWR) ; 
35 

36 srand ( (int) getpid ( ) ) ; 

37 while (1) { 

printf (" [Filosofo %d] pensando. . An", n_filosofo) ; 
sleep(rand() % MAX_TIME_PENSAR) ; // Pensar. 

40 

mq_receive (qHandlerMesa, buffer, sizeof (buf f er ) , NULL); 

42 

43 // Hambriento (coger palillos) . . . 

mq_receive (qHandlerlzq, buffer, sizeof (buf fer) , NULL); 

mq_receive (qHandlerDer, buffer, sizeof (buf fer ) , NULL); 
46 // Comiendo . . . 

printf (" [Filosofo %d] comiendo ... \n" , n_filosofo) ; 

48 sleep (rand () % MAX_TIME_COMER) ; // Comer. 

49 // Dejar palillos... 

mq_send (qHandler I zq, buffer, sizeof (buf fer) , 0); 
51 mq_send (qHandlerDer , buffer, sizeof (buf fer) , 0); 

52 

mq_send (qHandlerMesa, buffer, sizeof (buf fer) , 0); 



54 } 

55 } 
56 

void controlador (int senhal) { 

58 printf (" [Filosofo %d] Finalizado (SIGINT) \n", getpid ()); 

59 exit (EXIT_SUCCESS) ; 

60 } 




La biblioteca 



hilos de 
ICE 




C . 1 . Fundament os basic os 



ZeroC 



Figura C.l: ZeroC ICE es un 
middleware de comunicacio- 
nes que se basa en la filoso- 
fia de CORBA pero con una 
mayor simplicidad y practici- 
dad. 



ICE [Internet Communication Engine) [6] es un middleware de co- 
municaciones orientado a objetos, es decir, ICE proporciona herra- 
mientas, APIs, y soporte de bibliotecas para construir aplicaciones dis- 
tribuidas cliente-servidor orientadas a objetos. 

Una aplicacion ICE se puede usar en entornos heterogeneos. Los 
clientes y los servidores pueden escribirse en diferentes lenguajes de 
programacion, pueden ejecutarse en distintos sistemas operativos y en 
distintas arquitecturas, y pueden comunicarse empleando diferentes 
tecnologias de red. La tabla C.l resume las principales caracteristicas 
de ICE. 

Los principales objetivos de diseno de ICE son los siguientes: 

■ Middleware listo para usarse en sistemas heterogeneos. 

■ Proveee un conjunto completo de caracteristicas que soporten el 
desarrollo de aplicaciones distribuidas reales en un amplio rango 
de dominios. 

■ Es facil de aprender y de usar. 

■ Proporciona una implementacion eficiente en ancho de banda, 
uso de memoria y CPU. 
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Nombre 


Internet Communications Engine (ICE) 


Definido por 


ZeroC Inc. (http : / / www . zeroc . com) 


Documentacion 


http : / /doc . zeroc . com/ display /Doc /Home 


Lenguajes 


C++, Java, C#, Visual Basic, Python, PHP, Ruby 


Plataformas 


Windows, Windows CE, Unix, GNU/Linux, *BSD 
OSX, Symbian OS, J2RE 1.4 o superior, J2ME 


Destacado 


APIs claras y bien disenadas 

Conjunto de servicios muy cohesionados 

Despliegue, persistencia, cifrado... 


Descargas 


http: / / zeroc. com/ download . html 



Tabla C.l: ZeroC ICE. Resumen de caracteristicas. 



■ Implementacion basada en la seguridad. 

Para instalar ICE en sistemas operativos Debian GNU/Linux, eje- 
cute los siguientes comandos: 

$ sudo apt -get update 

$ sudo apt-get install zeroc-ice34 



C.2. Manejo de hilos 



ICE proporciona distintas utilidades para la gestion de la concu- 
rrencia y el manejo de hilos. Respecto a este ultimo aspecto, ICE pro- 
porciona una abstraccion muy sencilla para el manejo de hilos con el 
objetivo de explotar el paralelismo mediante la creacion de hilos dedi- 
cados. Por ejemplo, seria posible crear un hilo especifico que atenda 
las peticiones de una interfaz grafica o crear una serie de hilos en- 
cargados de tratar con aquellas operaciones que requieren una gran 
cantidad de tiempo, ejecutandolas en segundo piano. 

En este contexto, ICE proporciona una abstraccion de hilo muy 
sencilla que posibilita el desarrollo de aplicaciones multihilo altamen- 
te portables e independientes de la plataforma de hilos nativa. Esta 
abstraccion esta representada por la clase IceUtil::Thread. 



ICE maneja las peticiones a los servidores mediante un pool 
de hilos con el objetivo de incrementar el rendimiento de la 
aplicacion. El desarrollador es el responsable de gestionar el 
acceso concurrente a los datos. 



Como se puede apreciar en el siguiente listado de codigo, Thread es 
una clase abstracta con una funcion virtual pura denominada run(). 
El desarrollador ha de implementar esta funcion para poder crear un 
hilo, de manera que run() se convierta en el punto de inicio de la eje- 
cucion de dicho hilo. Note que no es posible arrojar excepciones desde 
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esta funcion. El nucleo de ejecucion de ICE instala un manejador de 
excepciones que llama a la funcion ::std::terminate() si se arroja alguna 
excepcion. 



Listado C.l: La clase IceUtil::Thread 



class Thread :virtual public Shared { 
public: 

3 

4 // Funcion a implementar por el desarrollador . 

5 virtual void run () =0; 
6 

7 ThreadControl start (size_t stBytes = 0) ; 

ThreadControl start (size_t stBytes, int priority); 
ThreadControl getThreadControl () const; 
bool isAlive () const; 

11 

bool operator— (const Threads) const; 
bool operator!= (const Threads) const; 

14 bool operator< (const Threads) const; 

15 }; 

16 

typedef Handle<Thread> ThreadPtr; 



El resto de funciones de Thread son las siguientes: 




start(), cuya responsabilidad es arrancar al hilo y llamar a la 
funcion run(). Es posible especificar el tamano en bytes de la pila 
del nuevo hilo, asi como un valor de prioridad. El valor de retorno 
de startQ es un objeto de tipo ThreadControl, el cual se discutira 
mas adelante. 

getThreadControl(), que devuelve el objeto de la clase Thread- 
Control asociado al hilo. 

id(), que devuelve el identificador unico asociado al hilo. Este va- 
lor dependera del soporte de hilos nativo (por ejemplo, POSIX 
pthreads) . 

isAlivefJ. que permite conocer si un hilo esta en ejecucion, es 
decir, si ya se llamo a startQ y la funcion run() no termino de 
ejecutarse. 

La sobrecarga de los operadores de comparacion permiten ha- 
cer uso de hilos en contenedores de STL que mantienen relacio- 
nes de orden. 



Figura C.2: Abstraction gra- 
fica del problema de los filo- 
sofos comensales, donde cln- 
co filosofos plensan y com- 
parten clnco pallllos para co- 
mer. 



Para mostrar como llevar a cabo la implementacion de un hilo es- 
pecifico a partir de la biblioteca de ICE se usara como ejemplo uno de 
los problemas clasicos de sincronizacion: el problema de los filosofos 
comensales, discutido en la seccion 2.3.3. 

Basicamente, los filosofos se encuentran comiendo o pensando. To- 
dos comparten una mesa redonda con cinco sillas, una para cada fi- 
losofo. Cada filosofo tiene un plato individual con arroz y en la mesa 
solo hay cinco palillos, de manera que cada filosofo tiene un palillo a 
su izquierda y otro a su derecha. 
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Cuando un filosofo piensa, entonces se abstrae del mundo y no 
se relaciona con ningiin otro filosofo. Cuando tiene hambre, entonces 
intenta coger a los palillos que tiene a su izquierda y a su derecha (ne- 
cesita ambos). Naturalmente, un filosofo no puede quitarle un palillo 
a otro filosofo y solo puede comer cuando ha cogido los dos palillos. 
Cuando un filosofo termina de comer, deja los palillos y se pone a 
pensar. 

La solucion que se discutira en esta seccion se basa en implemen- 
tar el filosofo como un hilo independiente. Para ello, se crea la clase 
FilosofoThread que se expone a continuacion. 



Listado C.2: La clase FilosofoThread 



#ifndef FILOSOFO 

#define FILOSOFO 

3 

#include <iostream> 
#include <IceUtil/Thread . h> 
#include <Palillo.h> 

7 

#define MAX_COMER 3 
#define MAX_PENSAR 7 

10 

11 using namespace std; 
12 

13 class FilosofoThread : public IceUtil :: Thread { 

14 

15 public: 

FilosofoThread (const ints id, Palillo* izq, Palillo *der) ; 

17 

18 virtual void run (); 

19 

20 private: 

void coger_palillos (); 

25 void de jar_palillos (); 

23 void comer () const; 

24 void pensar () const; 

25 

26 int _id; 

Palillo *_plzq, *_pDer; 

} ; 

29 

30 #endif 
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La implementacion de la funcion runQ es trivial a partir de la des- 
cripcion del enunciado del problema. 



Listado C.3: La funcion FilosofoThread::run() 



1 void 

2 FilosofoThread: : run () 

3 { 

4 while (true) { 

coger_palillos () ; 
comer ( ) ; 

de jar_palillos () ; 
pensar ( ) ; 

1 

10 } 



El problema de concurrencia viene determinado por el acceso de los 
filosofos a los palillos, los cuales representan la seccion critica asocia- 
da a cada uno de los hilos que implementan la vida de un filosofo. En 
otras palabras, es necesario establecer algun tipo de mecanismo de 
sincronizacion para garantizar que dos filosofos no cogen un mismo 
palillo de manera simultanea. Antes de abordar esta problematica, se 
mostrara como lanzar los hilos que representan a los cinco filosofos. 



El problema de los filosofos comensales es uno de los proble- 
mas clasicos de sincronizacion y existen muchas modificacio- 
nes del mismo que permiten asimilar mejor los conceptos teo- 
ricos de la programacion concurrente. 



El siguiente listado muestra el codigo basico necesario para lanzar 
los filosofos (hilos). 

Note como en la linea (23) se llama a la funcion runQ de Thread para 
comenzar la ejecucion del mismo. Los objetos de tipo ThreadControl 
devueltos se almacenan en un vector para, posteriormente, unir los 
hilos creados. Para ello, se hace uso de la funcion joinQ de la clase 
ThreadControl, tal y como se muestra en la linea [29] . 
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Listado C.4: Creacion y control de hilos con ICE 



#include <IceUtil/Thread . h> 
5 include <vector> 
#include <Palillo.h> 
#include <Filosofo.h> 

5 

#define NUM 5 

7 

int main (int argc, char *argv[]) { 



std : : vector<Palillo*> palillos; 

10 std : : vector<IceUt il : : ThreadControl> threads; 

11 int i; 

12 

13 // Se instancian los palillos. 

14 for (i = 0; i < NUM; i++) 

15 palillos . push_back (new Palillo); 
16 

17 // Se instancian los f ilosof os . 

18 for (i = 0; i < NUM; i++) { 

19 // Cada filosofo conoce los palillos 

20 // que tiene a su izda y derecha. 

21 IceUtil : : ThreadPtr t = 

new Filosof oThread (i, palillos [i], palillos [ (i + 1) % NUM] ) ; 

23 // start sobre hilo devuelve un objeto ThreadControl . 

24 threads .push_back (t->start ( ) ) ; 
2 } 

26 

27 // 'Union' de los hilos creados. 

28 std :: vector<IceUtil :: ThreadControl> :: iterator it; 

29 for (it = threads .begin () ; it != threads . end () ; ++it) it->join(); 

30 

31 return 0 ; 



32 } 



C.3. Exclusion mutua basic a 

El problema de los filosofos plantea la necesidad de algun tipo de 
mecanismo de sincronizacion basico para garantizar el acceso exclu- 
sive) sobre cada uno de los palillos. La opcion mas directa consiste en 
asociar un cerrojo a cada uno de los palillos de manera individual. 
Asi, si un filosofo intenta coger un palillo que esta libre, entonces lo 
cogera adquiriendo el cerrojo, es decir, cerrdndolo. Si el palillo esta 
ocupado, entonces el filosofo esperara hasta que este libre. 



Tipicamente, las operaciones para adquirir y liberar un cerrojo 
se denominan lockf) y unlockQ, respectivamente. La metafora de 
cerrojo representa perfectamente la adquisicion y liberacion de 
recursos compartidos. 




ICE proporciona la clase Mutex para modelar esta problematica de 
una forma sencilla y directa. 
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Listado C.5: La clase IceUtil::Mutex 



class Mutex { 
2 public : 

Mutex ( ) ; 
4 Mutex (MutexProtocol p) ; 
-Mutex ( ) ; 

6 

void lock () const; 
bool tryLock () const; 
void unlock () const; 

10 

11 typedef LockT<Mutex> Lock; 

12 typedef TryLockT<Mutex> TryLock; 

13 }; 



Las funciones miembro mas importantes de esta clase son las que 
permiten adquirir y liberar el cerrojo: 

■ lock(), que intenta adquirir el cerrojo. Si este ya estaba cerrado, 
entonces el hilo que invoco a la funcion se suspende hasta que el 
cerrojo quede libre. La llamada a dicha funcion retorna cuando 
el hilo ha adquirido el cerrojo. 

■ tryLock(), que intenta adquirir el cerrojo. A diferencia de lockQ, 
si el cerrojo esta cerrado, la funcion devuelve false. En caso con- 
trario, devuelve true con el cerrojo cerrado. 

■ unlockQ. que libera el cerrojo. 

Es importante considerar que la clase Mutex proporciona un meca- 
nismo de exclusion mutua basico y no recursivo, es decir, no se debe 
llamar a lockQ mas de una vez desde un hilo, ya que esto provocara un 
comportamiento inesperado. Del mismo modo, no se deberia llamar a 
unlockQ a menos que un hilo haya adquirido previamente el cerrojo 
mediante lockQ. En la siguiente seccion se estudiara otro mecanismo 
de sincronizacion que mantiene una semantica recursiva. 

La clase Mutex se puede utilizar para gestionar el acceso concu- 
rrente a los palillos. En la solucion planteada a continuacion, un pali- 
llo es simplemente una especializacion de IceUtil::Mutex con el objetivo 
de incrementar la semantica de dicha solucion. 



Listado C.6: La clase Palillo 



fifndef PALILLO 

fdefine PALILLO 

3 

4 #include <IceUtil/Mutex . h> 

5 

6 class Palillo : public IceUtil :: Mutex { 

v }; 

8 

fendif 



Para que los nlosofos puedan utilizar los palillos, habra que utilizar 
la funcionalidad previamente discutida, es decir, las funciones lockQ y 
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unlockQ, en las funciones coger_palillosQ y dejar_palillosQ. La solucion 
planteada garantiza que no se ejecutaran dos llamadas a lockQ sobre 
un palillo por parte de un mismo hilo, ni tampoco una llamada sobre 
unlockQ si previamente no se adquirio el palillo. 



Listado C.7: Acceso concurrente a los palillos 



l void 

Filosof oThread : : coger_palillos () 

3 { 

4 _pIzq->lock ( ) ; 

5 _pDer->lock ( ) ; 

6 } 
7 

void 

Filosof oThread :: de jar_palillos () 

10 < 

11 _pIzq->unlock ( ) ; 

12 _pDer->unlock ( ) ; 

13 } 



La solucion planteada es poco flexible debido a que los filosofos 
estan inactivos durante el periodo de tiempo que pasa desde que dejan 
de pensar hasta que cogen los dos palillos. Una posible variacion a la 
solucion planteada hubiera sido continuar pensando (al menos hasta 
un numero maximo de ocasiones) si los palillos estan ocupados. En 
esta variacion se podria utilizar la funcion tryLockQ para modelar dicha 
problematica. 



Si todos los filosofos cogen al mismo tiempo el palillo que esta 
a su izquierda se producira un interbloqueo ya que la solucion 
planteada no podria avanzar hasta que un filosofo cqja ambos 
palillos. 



C.3.1. Evitando interbloqueos 

El uso de las funciones lockQ y unlockQ puede generar problemas 
importantes si, por alguna situacion no controlada, un cerrojo previa- 
mente adquirido con lockQ no se libera posteriormente con una llama- 
da a unlockQ. El siguiente listado de codigo muestra esta problematica. 

En la linea (7), la sentencia return implica abandonar mi_JuncionQ 
sin haber liberado el cerrojo previamente adquirido en la linea fjf). En 
este contexto, es bastante probable que se genere una potencial si- 
tuacion de interbloqueo que paralizaria la ejecucion del programa. La 
generacion de excepciones no controladas representa otro caso repre- 
sentative de esta problematica. 




C.3. Exclusion mutua basica 
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Aunque exlsten diversos esquemas para evitar y recuperarse 
de un interbloqueo, los sistemas operativos modernos suelen 
optar por asumir que nunca se produciran, delegando en el 
programador la implementacion de soluciones seguras. 



Listado C.8: Potencial interbloqueo 



tinclude <IceUtil/Mutex . h> 

2 

! class Test { 
public : 

void mi_funcion () { 
_mutex . lock ( ) ; 
7 for (int i = 0; i < 5; i++) 

if (i == 3) return; // Generara un problema... 
_mutex . unlock ( ) ; 

D 1 
11 

12 private: 

13 IceUtil : :Mutex _mutex; 

14 }; 
15 

16 int main (int argc, char *argv[]) { 

17 Test t; 

t .mi_f uncion ( ) ; 
return 0 ; 

20 } 



Para evitar este tipo de problemas, la clase Mutex proporciona las 
deflniciones de tipo Lock y TryLock, que representan plantillas muy 
sencillas compuestas de un constructor en el que se llama a lockQ y 
tryLockQ, respectivamente. En el destructor se llama a unlockQ si el 
cerrojo fue previamente adquirido cuando la plantilla quede fuera de 
ambito. En el ejemplo anterior, seria posible garantizar la liberacion 
del cerrojo al ejecutar return, ya que quedaria fuera del alcance de la 
funcion. El siguiente listado de codigo muestra la modificacion reali- 
zada para evitar interbloqueos. 




Es recomendable usar siempre Lock y TryLock en lugar de las 
funciones lockQ y unlock para facilitar el entendimiento y la 
mantenlbilidad del codigo. 
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Listado C.9: Evitando interbloqueos con Lock 



#include <IceUtil/Mutex . h> 

2 

3 class Test { 
public : 

void mi_funcion () { 

IceUtil : :Mutex : : Lock lock (_mutex) ; 
for (int i = 0; i < 5; i++) 

if (i == 3) return; // Ningun problema... 
9 } // El destructor de lock libera el cerrojo. 
10 

11 private: 

12 IceUtil : :Mutex _mutex; 

13 }; 




No olvlde liberar un cerrojo solo si fue prevlamente adquirido y 
llamar a unlockf) tantas veces como a lock() para que el cerrojo 
quede dlsponlble para otro hllo. 



C.3.2. Flexibilizando el concepto de mutex 

Ademas de proporcionar cerrojos con una semantica no recursiva, 
ICE tambien proporciona la clase IceUtil: :RecMutex con el objetivo de 
que el desarrollador pueda manejar cerrojos recursivos. La interfaz de 
esta nueva clase es exactamente igual que la clase IceUtil: Mutex. 



Listado C.10: La clase IceUtil: :RecMutex 



class RecMutex { 
public : 

3 RecMutex ( ) ; 

RecMutex (MutexProtocol p) ; 
-RecMutex ( ) ; 

6 

void lock () const; 
bool tryLock () const; 
void unlock () const; 

10 

11 typedef LockT<RecMutex> Lock; 

typedef TryLockT<RecMutex> TryLock; 

13 }; 



Sin embargo, existe una diferencia fundamental entre ambas. In- 
ternamente, el cerrojo recursivo esta implementado con un contador 
inicializado a cero. Cada llamada a lockf) incrementa el contador, mien- 
tras que cada llamada a unlockf) lo decrementa. El cerrojo estara dis- 
ponible para otro hilo cuando el contador alcance el valor de cero. 



C.4. Introduciendo monitores 
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C.4. Introduciendo monitores 

Tanto la clase Mutex como la clase MutexRec son mecanismos de 
sincronizacion basicos que permiten que solo un hilo este activo, en 
un instante de tiempo, dentro de la seccion critica. En otras palabras, 
para que un hilo pueda acceder a la seccion critica, otro ha de aban- 
donarla. Esto implica que, cuando se usan cerrojos, no resulta posible 
suspender un hilo dentro de la seccion critica para, posteriormente, 
despertarlo cuando se cumpla una determinada condicion. 



®Las soluciones de alto nivel permiten que el desarrollador ten- 
ga mas flexibilidad a la hora de solucionar un problema. Este 
planteamiento se aplica perfectamente al uso de monitores. 



Para tratar este tipo de problemas, la biblioteca de hilos de ICE 
proporciona la clase Monitor. En esencia, un monitor es un meca- 
nismo de sincronizacion de mas alto nivel que, al igual que un cerro- 
jo, protege la seccion critica y garantiza que solamente pueda existir 
un hilo activo dentro de la misma. Sin embargo, un monitor permite 
suspender un hilo dentro de la seccion critica posibilitando que otro 
hilo pueda acceder a la misma. Este segundo hilo puede abandonar el 
monitor, liberandolo, o suspenderse dentro del monitor. De cualquier 
modo, el hilo original se despierta y continua su ejecucion dentro del 
monitor. Este esquema es escalable a multiples hilos, es decir, varios 
hilos pueden suspenderse dentro de un monitor. 

Desde un punto de vista general, los monitores proporcionan un 
mecanismo de sincronizacion mas flexible que los cerrojos, ya que es 
posible que un hilo compruebe una condicion y, si esta es falsa, el hijo 
se pause. Si otro hilo cambia dicha condicion, entonces el hilo original 
continua su ejecucion. 

El siguiente listado de codigo muestra la declaracion de la clase 
IceUtil::Monitor. Note que se trata de una clase que hace uso de plan- 
tillas y requiere como parametro bien Mutex o RecMutex, en funcion 
de si el monitor mantendra una semantica no recursiva o recursiva. 

Las funciones miembro de esta clase son las siguientes: 

■ lock(), que intenta adquirir el monitor. Si este ya estaba cerrado, 
entonces el hilo que la invoca se suspende hasta que el monitor 
quede disponible. La llamada retorna con el monitor cerrado. 

■ tryLock(), que intenta adquirir el monitor. Si esta disponible, la 
llamada devuelve true con el monitor cerrado. Si este ya estaba 
cerrado antes de relizar la llamada, la funcion devuelve false. 

■ unlock(), que libera el monitor. Si existen hilos bloqueados, en- 
tonces uno de ellos se despertara y cerrara de nuevo el monitor. 
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template <class T> 
2 class Monitor { 
public : 
void lock () const; 
void unlock () const; 
bool tryLock () const; 

7 



void wait () const; 

bool timedWait (const Times) const; 

10 void notify (); 

11 void notifyAll (); 
12 

13 typedef LockT<Monitor<T> > Lock; 

14 typedef TryLockT<Monitor<T> > TryLock; 

15 }; 



■ wait(), que suspende al hilo que invoca a la funcion y, de manera 
simultanea, libera el monitor. Un hilo suspendido por waitQ se 
puede despertar por otro hilo que invoque a la funcion notifyQ o 
notifyAllQ. Cuando la llamada retorna, el hilo suspendido conti- 
nua su ejecucion con el monitor cerrado. 

■ timedWait(), que suspende al hilo que invoca a la funcion hasta 
un tiempo especificado por parametro. Si otro hilo invoca a no- 
tifyO o notifyAllQ despertando al hilo suspendido antes de que el 
timeout expire, la funcion devuelve true y el hilo suspendido re- 
sume su ejecucion con el monitor cerrado. En otro caso, es decir, 
si el timeout expira, timedWaitQ devuelve false. 

■ notify (), que despierta a un unico hilo suspendido debido a una 
invocacion sobre waitQ o timedWaitQ. Si no existiera ningun hilo 
suspendido, entonces la invocacion sobre notifyQ se pierde. Lle- 
var a cabo una notificacion no implica que otro hilo reanude su 
ejecucion inmediatamente. En realidad, esto ocurriria cuando el 
hilo que invoca a waitQ o timedWaitQ o libera el monitor. 

■ notifyAllfJ. que despierta a todos los hilos suspendidos por waitQ 
o timedWaitQ. El resto del comportamiento derivado de invocar a 
esta funcion es identico a notifyQ. 



A 



No olvide comprobar la condicion asociada al uso de wait siem- 
pre que se retorne de una llamada a la misma. 



C.4.1. Ejemplo de uso de monitores 



Imagine que desea modelar una situacion en un videojuego en la 
que se controlen los recursos disponibles para acometer una deter - 
minada tarea. Estos recursos se pueden manipular desde el punto de 
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: Consumidor 



get 0 




: Productor 



notify 



wait 0 
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Figure C.3: Representacion grafica del uso de un monitor. 



vista de la generaciOn o producciOn y desde el punto de vista de la 
destrucciOn o consumiciOn. En otras palabras, el problema clasico del 
productor/consumidor. 

Por ejemplo, imagine un juego de acciOn de tercera persona en el 
que el personaje es capaz de acumular slots para desplegar algun 
tipo de poder especial. Inicialmente, el personaje tiene los slots vacios 
pero, conforme el juego evoluciona, dichos slots se pueden rellenar 
atendiendo a varios criterios independientes. Por ejemplo, si el jugador 
acumula una cantidad determinada de puntos, entonces obtendria un 
slot. Si el personaje principal vence a un enemigo con un alto nivel, 
entonces obtendria otro slot. Por otra parte, el jugador podria hacer 
uso de estas habilidades especiales cuando asi lo considere, siempre 
y cuando tenga al menos un slot relleno. 

Este supuesto plantea la problematica de sincronizar el acceso con- 
currente a dichos slots, tanto para su consumo como para su genera- 
ciOn. Ademas, hay que tener en cuenta que sOlo sera posible consumir 
un slot cuando haya al menos uno disponible. Es decir, la problema- 
tica discutida tambien plantea ciertas restricciones o condiciones que 
se han de satisfacer para que el jugador pueda lanzar una habilidad 
especial. 

En este contexto, el uso de los monitores proporciona gran flexibi- 
lidad para modelar una soluciOn a este supuesto. El siguiente listado 
de cOdigo muestra una posible implementaciOn de la estructura de da- 
tos que podria dar soporte a la soluciOn planteada, haciendo uso de 
los monitores de la biblioteca de hilos de ICE. 
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Listado C.12: Utilizando monitores 



#include <IceUtil/Monitor . h> 
#include <IceUtil/Mutex . h> 
#include <deque> 

4 

using namespace std; 

6 

template<class T> 
8 class Queue : public IceUtil : :Monitor<IceUtil : :Mutex> { 
public : 



10 void put (const T& item) { // Anade un nuevo item. 

IceUtil : :Monitor<IceUtil: :Mutex> : : Lock lock ( *this) ; 

12 _queue . push_back ( item) ; 

13 notify ( ) ; 
} 

15 T get () { // Consume un item. 

IceUtil : :Monitor<IceUtil : :Mutex> : : Lock lock ( *this) ; 
17 while (_queue . size ( ) == 0) 

wait ( ) ; 

19 T item = _queue . front () ; 

20 _queue . pop_f ront ( ) ; 

21 return item; 

22 } 
23 

24 private: 

25 deque<T> _queue; // Cola de doble entrada. 

26 }; 



Como se puede apreciar, la clase deflnida es un tipo particular de 
monitor sin semantica recursiva, es decir, definido a partir de IceU- 
til::Mutex. Dicha clase tiene como variable miembro una cola de doble 
entrada que maneja tipos de datos genericos, ya que la clase deflni- 
da hace uso de una plantilla. Ademas, esta clase proporciona las dos 
operaciones tipicas de put() y get() para afiadir y obtener elementos. 

Hay, sin embargo, dos caracteristicas importantes a destacar en el 
diseno de esta estructura de datos: 

1 . El acceso concurrente a la variable miembro de la clase se contro- 
la mediante el propio monitor, haciendo uso de la funcion lockQ 
(lineas (TT) y (jjj). 

2. Si la estructura no contiene elementos, entonces el hilo se sus- 
pende mediante waitQ (lineas [17-18]) hasta que otro hilo que eje- 
cute put(j realice la invocacion sobre notifyO (linea fijTj) . 




No olvide... usar Lock y Try Lock para evitar posibles interblo- 
queos causados por la generacion de alguna excepcion o una 
termlnacion de la funcion no prevista inicialmente. 



Recuerde que para que un hilo bloqueado por waitQ reanude su 
ejecucion, otro hilo ha de ejecutar notifyO y liberar el monitor me- 
diante unlockQ. Sin embargo, en el anterior listado de codigo no existe 
ninguna llamada explicita a unlockQ. ^Es incorrecta la solucion? La 
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respuesta es no, ya que la liberacion del monitor se delega en Lock 
cuando la funcion put() finaliza, es decir, justo despues de ejecutar la 
operacion notifyO en este caso particular. 

Volviendo al ejemplo anterior, considere dos hilos distintos que in- 
teractuan con la estructura creada, de manera generica, para almace- 
nar los slots que permitiran la activacion de habilidades especiales por 
parte del jugador virtual. Por ejemplo, el hilo asociado al productor 
podria implementarse de la siguiente forma: 

Suponiendo que el codigo del consumidor sigue la misma estruc- 
tura, pero extrayendo elementos de la estructura de datos comparti- 
da, entonces seria posible lanzar distintos hilos para comprobar que 
el acceso concurrente sobre los distintos slots se realiza de manera 
adecuada. Ademas, seria sencillo visualizar, mediante mensajes por la 
salida estandar, que efectivamente los hilos consumidores se suspen- 
den en waitQ hasta que hay al menos algun elemento en la estructura 
de datos compartida con los productores. 



Listado C.13: Hilo productor de slots 



class Productor : public IceUtil :: Thread { 
public : 

Productor (Queue<string> *_q) : 
4 _queue (_q) { } 

5 

void run ( ) { 

for (int i = 0; i < 5; i++) { 

IceUtil: : ThreadControl : : sleep 
( IceUtil :: Time :: seconds (rand ( ) % 7)); 

10 _queue->put ( "TestSlot" ) ; 

11 } 
1 

13 

private : 

15 Queue<string> *_queue; 

16 }; 



A continuacion, resulta importante volver a discutir la solucion 
planteada inicialmente para el manejo de monitores. En particular, la 
implementacion de las funciones miembro put() y get(j puede generar 
sobrecarga debido a que, cada vez que se anade un nuevo elemento a 
la estructura de datos, se realiza una invocacion. Si no existen hilos 
esperando, la notificacion se pierde. Aunque este hecho no conlleva 
ningun efecto no deseado, puede generar una reduccion del rendi- 
miento si el numero de notiflcaciones se dispara. 

Una posible solucion a este problema consiste en llevar un control 
explicito de la existencia de consumidores de informacion, es decir, 
de hilos que invoquen a la funcion get(). Para ello, se puede incluir una 
variable miembro en la clase Queue, planteando un esquema mucho 
mas eficiente. 
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El uso de alguna estructura de datos adicional puede facilitar 
el diseno de una solucion. Este tlpo de planteamientos puede 
Incrementar la eficiencia de la solucion planteada aunque haya 
una minima sobrecarga. 



Como se puede apreciar en el siguiente listado, el hilo productor 
solo llevara a cabo una notiflcacion en el caso de que haya algun hilo 
consumidor en espera. Para ello, consulta el valor de la variable miem- 
bro _consumidoresEsperando. Por otra parte, los hilos consumidores, 
es decir, los que invoquen a la funcion get() incrementan dicha variable 
antes de realizar un waitQ, decrementandola cuando se despierten. 



Listado C.14: Utilizando monitores (II) 



#include <IceUtil/Monitor . h> 
#include <IceUtil/Mutex . h> 
#include <deque> 

4 

template<class T> 

class Queue : public IceUtil : :Monitor<IceUtil : :Mutex> { 
public : 



Queue () : _consumidoresEsperando ( 0 ) {} 

9 

10 void put (const T& item) { // Anade un nuevo item. 

IceUtil : :Monitor<IceUtil : :Mutex> : : Lock lock ( *this) ; 

12 _queue . push_back ( item) ; 

13 if (_consumidoresEsperando) 

14 notify ( ) ; 
} 

16 

17 T get () { // Consume un item. 

IceUtil : :Monitor<IceUtil : :Mutex> : : Lock lock ( *this) ; 

19 while (_queue . size ( ) ==0) { 

20 try { 

21 _consumidoresEsperando++; 

22 wait(); 

23 _consumidoresEsperando — ; 

24 } 

25 catch (...) { 

26 _consumidoresEsperando — ; 

27 throw; 

28 } 

29 } 

T item = _queue . front () ; 
31 _queue . pop_f ront ( ) ; 

return item; 

J 

34 

35 private : 

std : : deque<T> _queue; // Cola de doble entrada. 
int _consumidoresEsperando; 

} ; 



Note que el acceso a la variable miembro _consumidoresEsperando 
es exclusivo y se garantiza gracias a la adquisicion del monitor justo 
al ejecutar la operacion de generacion o consumo de informacion por 
parte de algun hilo. 
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